Хеш фонды: что это такое и какие риски они несут

Содержание

что это такое и какие риски они несут

Подобные потери «весьма чувствительны» для всей мировой банковской системы. Так например, японский банк Nomura Holdings Inc. в этой истории потерял примерно $2 млрд, а швейцарский Credit Suisse – около $4 млрд.

Что же такое хедж-фонды и насколько они опасны для инвесторов и банкиров?

Хедж-фонд (hedge fund) – частный инвестиционный фонд. От банков и других инвестиционных фондов отличается минимальными законодательными ограничениями и широким набором инструментов, как правило, работает со сложными финансовыми инструментами.

Управляющие менеджеры хедж-фонда, профессиональные финансисты, по своему усмотрению распоряжаются инвестициями пула клиентов и сами выбирают, во что инвестировать: различные акции, облигации, драгоценные металлы, недвижимость, деривативы и пр. Главная цель хеджирования рисков – получить максимальную прибыль при минимальном риске. Прибыль делится между инвесторами пропорционально внесенным средствам.

Гонорар управляющего менеджера зависит от общей полученной годовой прибыли.

Хедж-фонды имеют некоторое сходство и с венчурными фондами, и с паевыми инвестиционными фондами (ПИФ), но есть и серьезные отличия. В частности, хедж-фонд работает только с большими капиталами. К примеру, купить пай в ПИФе можно и за $15, но капитал, который нужно внести в хедж-фонд — не менее $100 000 в офшорных юрисдикциях и не менее $5 млн в США.

Плюсы и минусы хедж-фондов

Плюсы

Возможность получения высокой прибыли. Хедж-фонды могут предложить средний годовой доход в 20-30%, иногда до 70%.
Гибкое реагирование на изменение конъюнктуры рынка. Для увеличения капитала нет строгой системы, правил или ограничений. Используются разнообразные стратегии, в том числе высокорисковые.
Хедж-фонды могут торговать (и, как правило, торгуют) с использованием кредитного плеча. Что сулит большую прибыль при относительно маленьких вложениях, но и чревато большими потерями.

Минусы

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

В России нет четкого законодательного регулирования хедж-фондов. В 2008 году был принят Приказ ФСФР № 08-19/пз-н «Об утверждении Положения о составе и структуре активов акционерных инвестиционных фондов и активов паевых инвестиционных фондов», которым было введено регулирования хедж-фондов. Немного про инструмент хеджирование также сказано в ФЗ «Об инвестиционных деятельности», налоговом законодательстве.

Благодарим за помощь в подготовке материала Кристину Клинову, начальника судебного отдела юридического управления Группы компаний «Результат».

Хеджевые фонды

№4(19), 2011

Научная студенческая конференция «Международное движение капитала и участие в нем стран и регионов мира»

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

Ключевые слова: хеджевые фонды, офшорные зоны

S.Bokher. Hedge Funds

The article covers the subject of hedge funds, their structure and casts doubt on hedge funds’ independence of the global market and their low degree of risk.

Key words: hedge funds, offshore zones

На сегодняшний день в мире существует множество способов заработать деньги при помощи спекулятивных операций. Однако люди или организаций, имеющие довольно крупные капиталы, вероятнее всего отдают предпочтение доверительному управлению и ищут возможность сэкономить, заработать больше и минимизировать степень неопределенности, которая окутывает абсолютно все экономические процессы. Чаще всего выбор падает на хеджевые фонды.

Так что же такое хедж-фонд, и какие преимущества он имеет перед остальными инвестиционными фондами? Прежде всего, хеджевый фонд — это частный, не ограниченный нормативным регулированием, либо подверженный более слабому регулированию инвестиционный фонд, недоступный широкому кругу лиц и управляемый профессиональным инвестиционным управляющим.

В качестве инвесторов выступают как физические, так и юридические лица, однако на 61% они финансируются из институциональных источников. В фонде есть управляющий и, инвесторы, которые полностью доверяют свой капитал хеджеру. Обычно инвестиционный управляющий имеет большой опыт реализации инвестиционных проектов и может предсказывать ключевые финансовые события.

В чем же, на наш взгляд, состоят преимущества хеджевых фондов?

Прежде всего, это свобода в выборе инвестиционного стиля. Фонд свободен в выборе тех стратегий, которые могут дать наилучший результат в текущих обстоятельствах. Так, например, одновременная торговля на различных рынках зачастую приносит достаточно высокие доходы, позволяя извлекать выгоду из разницы цен по одним и тем же активам. Помимо этого, проблема создания диверсифицированного портфеля, являющаяся практически неразрешимой для основного числа инвесторов, очень легко решается в рамках хедж-фонда. Наконец, инвесторы получают возможность объединить свои активы в единый пул, с огромным капиталом, который позволяет существенно снизить риски. Это один из примеров диверсификации рисков.

Однако на практике хедж фонды имеют свои недостатки. Во-первых, это ограниченный круг лиц и высокий уровень стартовых инвестиций. Например, в США для того чтобы вступить в хедж фонд, физическому лицу необходимо предоставить 5 млн.

долларов, а юридическому — 25 млн. долл., что накладывает значительные ограничения на их деятельность. Тем не менее, выход всегда находят. И, как не трудно догадаться, выход — это офшорные зоны, особенно Каймановы острова, Виргинские острова, Люксембург, Бермуды.

Во-вторых, деятельность фондов обычно слабо регулируется законодательством. Первые хедж фонды появились еще в США в 1940-х гг., когда впервые начали страховать открытые длинные позиции короткими. С начала 1990-х имел место бурный рост числа хедж-фондов, который был остановлен банкротством самого крупного на тот момент хеджевого фонда Long-Term Capital Management (LTCM). Это было шоком для всего мира, потому что данных фондом управляли Роберт Мертон и Майрон Шоулз, имеющие дипломы МИТ, нобелевские премии за исследования в области хеджирования и высокий авторитет на Уолл-Стрит. После банкротства LTCM доверие ко всем такого рода фондам резко упало: люди поняли, что даже гении могут совершить ошибку.

Интерес к хедж-фондам опять начал расти только в середине 2000-х гг. , вплоть до нового мирового финансового кризиса, не обошедшего стороной и хедж фонды. Их количество резко уменьшилось. Что же послужило тому причиной?

Известные американские миллиардеры, хеджеры и аналитики, Джеймс Симонс и Джордж Сорос нашли, кого обвинить в этом. Симонс считает, что во всем виноваты рейтинговые агентства. Для них выгодно завышать рейтинг компаниям или финасовым инструментам, так как часто им за это платят. Это притупило бдительность инвесторов, которые вложили деньги. А когда случился кризис, компании с завышенным рейтингом просто обанкротились, а хедж фонды понесли миллиардные убытки.

Джордж Сорос рассматривает проблему еще шире: по его мнению, все бремя ответственности падает на несовершенство нынешней финансовой систему.

Кроме того, количество хедж фондов уменьшилось вследствие еще одного явления. Управляющие фондами всегда привлекали инвесторов низкой степенью риска и высокой доходностью. Например, когда после испуга 2000 года NASDAQ потерял 70% стоимости, а весь рынок 30%, хедж фонды приносили стабильный доход в размере 15–20%.

Доверительные управляющие говорили клиентам: смотрите, мы можем формировать ваш портфель так, что вам неважно, падает рынок или растет. Мы, говорили они, можем убрать рыночный риск, построить инвестиционную стратегию, нейтральную к рынку, которая пусть и немного, но зарабатывает всегда. И это отсутствие корреляции портфеля с рынком в целом в условиях низких процентных ставок всех привлекало.

Сначала, конечно, все сомневались — как и во всем новом. А прошел год, полтора, люди смотрят: ну ведь работает, могут же? Значит, в этом что-то есть. И вот тогда, в 2002–2006 годах в отрасль и поступило большинство новых денег. Если в 2000 году всех хедж фондов было где-то 400, то в 2007 году — уже 14 тыс. Да, 2 трлн. долл. средств инвесторов в хедж фондах — кажется, это не очень много по сравнению с 50 трлн. в мировой системе доверительного управления. Но хедж фонды, в отличие от всех остальных, могли привлечь на эти 2 трлн. десятки триллионов заемных средств, что резко повысило их влияние на рынки капиталов.

Конечно, пара сотен гениальных трейдеров во всем мире могут построить фонды, постоянно генерирующие доход. Но для этого необходимы деривативы от надежных финансовых институтов для страхования рисков, активы, постоянно движущиеся против рынка, и относительно небольшой объем таких стратегий по отношению к рынку в целом. Но к 2008 году хедж фонды и стали рынком. А потом случился такой кризис, когда все активы стали себя вести одинаково плохо, то есть корреляция стала почти 100-процентная, никаких защит не осталось — ни географических, ни по классам активов. А банки и страховые компании, эмитирующие деривативы, то есть страховку от рынка, практически обанкротились. И все эти пресловутые нейтральные стратегии на 85% оказались коррелируемыми с рынком. И все самые совершенные инвестиционные модели обманули ожидания инвесторов.

На сегодняшний день хедж фонды не восстановили свою репутацию. Трейдеры считают нынешнюю ситуацию на рынке аналогичной тому, что происходило в 2008 году, однако теперь у инвесторов нет уверенности, что мировые регуляторы примут меры, чтобы успокоить рынки.

По данным Hedge Fund Research, в сентябре 2011 активы хеджевых фондов снизились в среднем на 2,8%, в третьем квартале — на 5,5%. Стратегии фондов, фокусирующихся на рынках акций, оказались безуспешными, активы этих фондов за девять месяцев 2011 года сократились на 8,7%, что соответствует динамике индекса Standard & Poor’s 500. В сентябре лишь две стратегии хедж фондов из 18, отслеживаемых Hedge Fund Research, оказались прибыльными.

Таким образом, мы можем заключить, что, несмотря на все преимущества: низкий уровень риска, высокую доходность и т. д., хеджевые фонды не смогли пережить кризис. На сегодня перспективы выглядят мрачно и проблема остается открытой. Нельзя с уверенностью сказать, что произойдет в дальнейшем с хеджевыми фондами.

Стратегия Первый Хедж Фонд

«Сбер Управление Активами» и «Сбер Инвестиции» — бренды, используемые АО «Сбер Управление Активами» для продвижения своих финансовых продуктов.
Акционерное общество «Сбер Управление Активами» зарегистрировано Московской регистрационной палатой 1 апреля 1996 года. Лицензия ФКЦБ России №045-06044-001000 от 7 июня 2002 года на осуществление деятельности по управлению ценными бумагами. Ознакомиться с условиями управления активами, получить сведения об АО «Сбер Управление Активами» и иную информацию, которая должна быть предоставлена в соответствии с федеральным законом и иными нормативными правовыми актами РФ, заинтересованные лица до заключения договора доверительного управления могут по адресу: 121170, г. Москва, ул. Поклонная, дом 3, корп.1, этаж 20, на сайте www.sber-am.ru, по телефону (495) 258 05 34 или в контактно-информационном центре по телефону (495) 500 55 50. Результаты деятельности управляющего по управлению ценными бумагами в прошлом не определяют доходы учредителя управления в будущем. Прежде чем принять решение об инвестировании, необходимо внимательно ознакомиться с договором доверительного управления и декларацией о рисках.

Заключаемый договор доверительного управления не является договором банковского вклада или банковского счета. Передаваемые в управление денежные средства не застрахованы в государственной корпорации «Агентство по страхованию вкладов» в соответствии с федеральным законом «О страховании вкладов в банках РФ», государство, ПАО Сбербанк и компания не дают никаких гарантий сохранности и возврата инвестируемых денежных средств. Услуги по доверительному управлению оказывает АО «Сбер Управление Активами». Денежные средства в управление получает АО «Сбер Управление Активами», а не ПАО Сбербанк. ПАО Сбербанк и АО «Сбер Управление Активами» являются разными лицами с самостоятельной ответственностью, не отвечающими по обязательствам друг друга. Услуги по доверительному управлению означает инвестирование денежных средств в ценные бумаги. инвестирование в ценные бумаги влечёт кредитные и рыночные риски, в том числе риск потери всех или части инвестированных денежных средств. Вложение в ценные бумаги всех имеющихся у клиента денежных средств или большей их части может привести к утрате всех его накоплений, а также банкротству клиента. Для направления жалоб, а также внесудебного разрешения споров, связанных с услугами доверительного управления, клиент вправе обратиться в компанию (почтовый адрес: 121170, г. Москва, ул. Поклонная, дом 3, корп.1, этаж 20, телефон: 8 (800) 555 55 50, эл. адрес: [email protected], интернет- сайт: www.sber-am.ru), в ПАО Сбербанк, в НАУФОР, в Центральный Банк РФ. В случае невозможности внесудебного урегулирования спора клиент вправе обратиться в суд.

ИПИФ финансовых инструментов «Сбер – Первый Хедж Фонд» внесен Банком России в реестр ПИФ 10.06.2020, правила доверительного управления № 4070-СД.

Топ-10 хедж-фондов мира

Хедж-фонд предполагает альтернативные инвестиции, использующие различные методы: производные инструменты с кредитным плечом, короткие продажи и другие спекулятивные стратегии с целью получения прибыли, превосходящей по доходности более широкий рынок. Хедж-фонды инвестируют как на внутреннем, так и на международном рынке.

Как правило, они устанавливают минимум $1 млн и ориентируются на состоятельных частных лиц, пенсионные фонды и институциональных инвесторов. Хедж-фонды неизменно несут более высокий риск, чем традиционные инвестиции.

Топ-10 хедж-фондов мира

1. Bridgewater Associates
Сопредседатель и сопредседатель правления по инвестициям Рэй Далио основал фирму в 1975 г. Компания предлагает четыре основных фонда:
— Pure Alpha, который фокусируется на активной инвестиционной стратегии;
— Pure Alpha Major Markets, который нацелен на подмножество вариантов, в которые инвестирует фонд Pure Alpha;
— All Weather, использующий стратегию распределения активов;
— Optimal Portfolio, который сочетает в себе аспекты фонда All Weather с активным управлением.

По состоянию на 30 апреля 2020 г. под управлением фонда находилось $138 млрд.

2. Renaissance Technologies
Математик Джим Саймонс основал Renaissance Technologies в 1982 г. Количественный хедж-фонд использует математические и статистические методы для выявления технических индикаторов, определяющих его стратегии автоматизированной торговли. Применяет свои методы к американским и международным акциям, долговым инструментам, фьючерсным, форвардным и валютным контрактам.

По состоянию на 31 декабря 2019 г. под управлением фонда находилось почти $166 млрд.

3. Man Group
Британский хедж-фонд имеет более чем 230-летний опыт торговли, начав свою деятельность в 1784 г. в качестве эксклюзивного поставщика рома для Королевских военно-морских сил, а затем занявшись торговлей сахаром, кофе и какао.

По состоянию на 31 декабря 2019 г. активы Man Group находились в управлении на $117,7 млрд.

4. AQR Capital Management
Клифф Элесс вместе с партнерами Джоном Лью, Робертом Крейлом и Дэвидом Кабиллером основал компанию в августе 1998 г. До этого четверка работала над созданием хедж-фонда в Goldman Sachs. Использует количественный анализ для разработки финансовых моделей, ориентированных на стоимостное и импульсное инвестирование.

По состоянию на 31 декабря 2019 г. под управлением AQR находилось $185,63 млрд.

5. Two Sigma Investments
Компания основана Джоном Овердеком и Дэвидом Сигелом в апреле 2002 г. Использует количественный анализ для построения математических стратегий, основанных на исторических ценовых моделях и других данных.

По состоянию на 31 декабря 2019 г. под управлением Two Sigma Investments
находилось $66,14 млрд.

6. Millennium Management
Основана в 1989 г. Компанию возглавляет председатель правления Исраэль Инглэндер, который основал Millennium с капиталом в $35 млн. после карьеры биржевого брокера, трейдера и специалиста на Американской фондовой бирже. Компания предлагает частным фондам дискреционные консультационные услуги.

По состоянию на 31 декабря 2019 г. под управлением компании Millennium находилось $42 млрд.

7. Elliott Management
Руководство компании описывает свой инвестиционный мандат как «чрезвычайно широкий», охватывающий практически все типы активов: проблемные ценные бумаги, акции, хеджирование и арбитражные позиции, сырьевые товары, ценные бумаги, связанные с недвижимостью и др. Компания основана Полом Сингером в 1977 г.

По состоянию на 31 декабря 2019 г. активы под управлением Elliott Management составляли $73,5 млрд., а чистые активы под управлением — $40 млрд.

8. BlackRock
Инвестиционный менеджер, управляющий триллионами активов. Самая крупная организация BlackRock, BlackRock Fund Advisors, работает с 1984 г. и управляет активами в размере $1,9 трлн.
Компания BlackRock Financial Management основана в 1994 г. и управляет активами на сумму $1,03 трлн. BlackRock Advisors также начала свою деятельность в 1994 г. и управляет активами на сумму $687,64 млрд.

9. Citadel Advisors
Основана в 1980 г. Специализируется на акциях, фиксированном доходе и макро-, сырьевых, кредитных и количественных стратегиях.

По состоянию на 31 декабря 2019 г. активы под управлением Citadel составляли $28,89 млрд.

10. Davidson Kempner Capital Management
Компания начала управлять капиталом инвесторов в 1987 г. Фокусируется на банкротствах, арбитраже слияний, проблемных инвестициях, акциях с привязкой к событиям и ситуациям реструктуризации.

По состоянию на 31 января 2020 г. под управлением Davidson Kempner находилось $35,9 млрд, а чистые активы под управлением составляли $33,1 млрд.

Читайте также: 5 самых ожидаемых дебютов IPO в 2021

БКС Мир инвестиций

Хедж-фонды сообщили о планах увеличить долю вложений в криптовалюту :: РБК.Крипто

Уже к 2026 году инвестиционные фонды планируют держать в цифровых активах около $312 млрд

Хедж-фонды к 2026 году планируют существенно нарастить долю вложений в криптовалюты, пишет Financial Times со ссылкой на исследование фонда Intertrust. По результатам опроса, проведенного среди 100 финансовых директоров хедж-фондов по всему миру, в среднем через пять лет они планируют держать в криптовалюте 7,2% своих активов. Основываясь на прогнозной оценке рынка хедж-фондов от аналитической компании Preqin, Intertrust прогнозирует, что к 2026 году хедж-фонды будут хранить в цифровых активах около $312 млрд.

Наибольший аппетит к риску продемонстрировали фонды из Северной Америки — в среднем они ожидают, что через пять лет 10,8% их активов будет приходиться на криптовалюты.

Как отмечает FT, точный размер вложений хедж-фондов в криптовалюту сейчас неизвестен, однако в этот актив уже инвестировали ряд известных фондов и их управляющих. Среди них — фонд Brevan Howard и управляющий-миллиардер Пол Тюдор Джонс.

Для фонда SkyBridge Capital, основанного бывшим директором по коммуникациям Белого дома Энтони Скарамуччи, биткоин вовсе стал основным источником прибыли — компания инвестировала в криптовалюту в конце 2020 года и сократила вложения в нее в апреле, незадолго до того, как актив резко упал в цене.

Как отмечает FT, далеко не все хедж-фонды разделяют оптимизм по поводу биткоина и других криптовалют. Например, в письме инвесторам в этом году фонд Elliot Management Пола Сингера указывал, что криптовалюты могут стать «величайшей аферой в истории».

В начале июня популярный американский брокер Interactive Brokers пообещал своим клиентам к концу лета предоставить доступ к торговле криптовалютой. Сейчас клиенты Interactive Brokers могут торговать фьючерсами на биткоин на электронной платформе брокера.

— Huobi: Россия вошла в число лидеров по росту спроса на цифровые активы

— Аналитик назвал причину возможного начала новой коррекции курса биткоина

— «Рынок ощутил слабость продавцов». Возможно ли подорожание биткоина

Больше новостей о криптовалютах вы найдете в нашем телеграм-канале РБК-Крипто.

Автор

Алексей Корнеев

Хедж-фонды компенсируют частными инвестициями убытки от ралли акций-мемов :: Новости :: РБК Инвестиции

Фото: Shutterstock

Хедж-фонды сокращают инвестиции в публичные компании и делают ставку на рост стоимости частных компаний и новые IPO в США, вытесняя венчурные и фонды роста. Об этом сообщает Wall Street Journal.

Хедж-фонды предложили 27% финансирования в ходе частных раундов в первом полугодии 2021 года, несмотря на то, что участвовали в 4% сделок, сообщает Goldman Sachs Group. С 2010 по 2020 год частные и венчурные инвестиции приносили в среднем в два раза больше прибыли в год, чем стратегии хедж-фондов.

D1 Capital Partners за первые три квартала 2021 года снизила свои инвестиции в публичные компании на 4%, частные инвестиции хедж-фонда выросли на 71%. Январское ралли акций-мемов таких компаний, как GameStop и AMC Entertainment Holdings 30% у D1 Capital Partners.

Whale Rock Capital Management потерял 11,2% на инвестициях в публичные компании. Доходы от частных инвестиций хедж-фонда сократили потери до 3,3% за первые три квартала.

Больше новостей об инвестициях вы найдете в нашем телеграм-канале «Сам ты инвестор!»

Инвестиции — это вложение денежных средств для получения дохода или сохранения капитала.

Различают финансовые инвестиции (покупка ценных бумаг) и реальные (инвестиции в промышленность, строительство и так далее). В широком смысле инвестиции делятся на множество подвидов: частные или государственные, спекулятивные или венчурные и прочие. Подробнее

Автор

Ксения Котченко

Что такое хедж-фонд | Хедж-фонды | Академия

По сути, хедж-фонд — причудливое название инвестиционного партнерства. Его участники — управляющий фонда (генеральный партнер) и инвесторы (партнеры с ограниченной ответственностью). Ограниченные партнеры вкладывают в фонд свои деньги, а генеральный управляет ими в соответствии с избранной стратегией. Цель фонда — максимизировать прибыли и устранить риски, поэтому его название образовано от слова «хеджировать». Пожалуй, на этом сходство с другими фондами, например, паевыми, заканчивается.

Название «хедж-фонд» закрепилось за этими структурами, поскольку они стремятся заработать как на росте, так и на падении рынков. Управляющие хедж-фондов одновременно занимают длинные и короткие позиции по акциям и другим активам (короткие позиции позволяют зарабатывать на снижении цен).

Есть и другие отличительные особенности хедж-фондов. Они являются частными инвестиционными партнерствами, предназначенными исключительно для богатых вкладчиков, и могут делать с их деньгами все, что пожелают в рамках заранее сформулированной стратегии. Подобный широкий простор может показаться рискованным — временами он таким и бывает. Некоторые из наиболее нашумевших скандалов в финансовой отрасли произошли с участием хедж-фондов. С другой стороны, высокая гибкость привлекает в хедж-фонды наиболее талантливых финансовых управляющих, демонстрирующих впечатляющие долгосрочные результаты.

Деятельность хедж-фонда — вымышленный пример

Чтобы лучше понять работу хедж-фондов и причину их популярности у инвесторов и управляющих, давайте создадим вымышленный фонд и проследим за его деятельностью в течение одного года. Назовем его, скажем, Value Opportunities Fund. В операционном соглашении — правовом документе, регулирующем деятельность фонда, — сказано, что управляющий получает 25% от дохода, превышающего 5% в год. Кроме того, инвестировать можно в любые активы.

Проспектом фонда заинтересовались 10 инвесторов, каждый вложил по 10 млн долларов. Таким образом, активы составляют 100 млн долларов. Все вкладчики подписали инвестиционный договор, похожий на форму для открытия счета, и выслали чеки напрямую брокеру фонда или его администратору. Администратор отразил их вложения в балансе фонда, а затем перенаправил брокеру. Обычно в роли администратора выступает бухгалтерская фирма. Теперь наш фонд открыт и готов к работе. Управляющий находит привлекательную возможность, звонит брокеру и отдает ему распоряжение вложить в нее все 100 млн.

Год прошел, и активы фонда выросли на 40%, до 140 млн долларов. Теперь, согласно действующему договору, первые 5% принадлежат инвесторам, а весь доход, превышающий эту сумму, распределяется в пропорции 25% на 75% между управляющим и инвесторами. Таким образом, из 40 млн, полученных по итогам года, будут вычтены 2 млн (5%), а оставшаяся сумма в 38 млн будет поделена между управляющим и инвесторами. Эти 5% называются «пороговой доходностью», поскольку управляющий, чтобы хорошо заработать, сначала должен ее превысить.

Исходя из результатов года и соглашения с инвесторами, управляющий получил 9,5 млн долларов. Инвесторы в общей сложности заработали 30,5 млн. Как видите, работа с хедж-фондом может быть очень прибыльным занятием. Если бы его активы составляли 1 млрд долларов, менеджер заработал бы 95 млн, инвесторы — 305 млн.

Конечно, зачастую управляющих критикуют за столь высокие компенсации. Однако люди, порицающие их (часто к этому прикладывают руку СМИ), забывают, что инвесторы тоже получили приличный куш. Когда вы слышали, чтобы инвестор успешного хедж-фонда жаловался на слишком высокий гонорар управляющего?

У хедж-фондов есть ряд преимуществ по сравнению с традиционными инвестиционными фондами. Среди них:

Конечно, не обошлось и без рисков:

Zero Hash привлекает 35 миллионов долларов в виде финансирования серии C под руководством

ЧИКАГО, 30 сентября 2021 г. (GLOBE NEWSWIRE) — Zero Hash, ведущая компания, занимающаяся инфраструктурой цифровых активов, которая предоставляет готовое решение для платформ для покупки, продажи, получения, отправки, получения и вознаграждения цифровых активов, сегодня объявила о выделении 35 миллионов долларов США. финансирование новой серии C. Инвестиционный раунд проводился Point72 Ventures вместе с партнерами NYCA, DriveWealth и другими. В раунде также приняли участие несколько известных бизнес-ангелов, в том числе Иммад Ахунд (основатель и генеральный директор Mercury), Калпеш Кападиа (основатель и генеральный директор Deserve), Итан Блох (генеральный директор и основатель Digit) и Джейсон Гарднер (основатель и генеральный директор Marqeta). .

«Zero Hash определяет совершенно новую финтех-вертикаль« цифровые активы как услуга ». Zero Hash — это платформа встроенной инфраструктуры B2B, которая позволяет любой платформе быстро и легко интегрировать цифровые активы в собственный опыт клиентов », — сказал Эдвард Вудфорд, основатель и генеральный директор. «Мы поддерживаем торговлю цифровыми активами и их хранение, программы вознаграждений с криптовалютой, а также доходность за счет стекинга и DeFi. Zero Hash берет на себя всю внутреннюю сложность и регулирует лицензирование, необходимое для предложения продуктов с цифровыми активами.

Zero Hash теперь используется некоторыми крупнейшими нео-банками (включая MoneyLion и Wirex) и известными брокерами-дилерами (включая deliciousworks и TradeStation). Zero Hash работает с некоторыми из крупнейших брендов экосистемы финансовых технологий и финансовых услуг для поддержки своих будущих криптовалютных предложений.

Компания почти удвоила количество сотрудников с начала 2021 года, а также недавно достигла прибыльности. Zero Hash теперь обеспечивает значительную часть всего мирового объема транзакций в цепочке.Компания будет использовать выручку от раунда для продолжения расширения своего предложения продуктов, в том числе в области DeFi и NFT. Вливание капитала позволит расширить команду за счет подразделений комплаенс, маркетинга, продуктов и инженерии. Компания также намеревается расширить свою глобальную систему лицензирования, а также осуществить стратегические приобретения.

«Zero Hash разработала уникальную платформу, которая помогает финтех-компаниям и финансовым учреждениям легко встраивать криптографические продукты и опыт в свои приложения гибким и совместимым образом», — сказал Адам Карсон, партнер Point72 Ventures. «Мы считаем, что встроенные финансовые решения, такие как платформа криптографического API Zero Hash, помогут сыграть важную роль в обеспечении более широкого внедрения цифровых активов, позволяя потребителям получать доступ к криптовалюте через финтех-приложения и бренды финансовых услуг, которые они уже используют и которым доверяют».

О Zero Hash:

Миссия Zero Hash — расширить возможности новаторов, предоставив доступ к финансовой системе 2.0. Zero Hash предоставляет полное решение под ключ, позволяющее платформам запускать цифровые активы и управлять клиентским опытом без каких-либо нормативных накладных расходов и небольшого технического лифта (вопрос конечных точек API).Zero Hash позволяет разработчикам и компаниям сосредоточиться на создании опыта и продуктов. Среди клиентов Zero Hash — нео-банки, брокеры-дилеры и платежные группы.

Zero Hash Holdings Ltd. — это корпорация C-Corp в штате Делавэр, которая полностью владеет Zero Hash LLC и Zero Hash Liquidity Services LLC.

Zero Hash LLC, дочерняя компания Zero Hash Holdings Ltd., является зарегистрированной в FinCen компанией по оказанию денежных услуг, а также регулируемой службой денежных переводов, которая может работать в 51 юрисдикции США. Zero Hash также имеет лицензию на виртуальную валюту от NYDFS.В Канаде Zero Hash LLC зарегистрирована в FINTRAC как компания, предоставляющая денежные услуги.

О Point72 Ventures:

Point72 Ventures — это глобальная стратегия венчурного капитала, возглавляемая разнообразным набором экспертов в предметной области, обладающих капиталом и полномочиями проводить раунды на всех этапах роста компании, от идеи до IPO. Команда инвестирует в основателей со смелыми идеями, которые используют новейшие технологии для трансформационных изменений во всех отраслях. Point72 Ventures предлагает предпринимателям доступ к опыту и знаниям, управленческим и техническим талантам, а также практической поддержке.Point72 Ventures с офисами в США и Европе является филиалом Point72, глобального управляющего активами, основанного Стивеном Коэном. Для получения дополнительной информации посетите p72.vc .

Контакты для прессы:

Нулевой хэш
Эдвард Вудфорд
(855) 744-7333 Внешний: 102
[email protected]

Point72 Ventures
Тиффани Галвин-Коэн

03 (203) -2052
[email protected]

Джоан Хэш, комитет по обеду коллег из Silas Craft

Задолго до того, как она начала собирать средства для Silas Craft Collegians, Джоан Хэш была хорошо знакома с тезкой программы .

Покойный доктор Сайлас Э. Крафт-старший возглавил открытие первой средней школы для чернокожих в округе Ховард — средней школы Харриет Табман в 1949 году — и был ее первым директором, пока в ней учились братья и сестры Хэша. Хотя он ушел, когда прибыл Хэш, его наследие прочно утвердилось.

«Он был другом семьи», — говорит Хэш, который входит в комитет по ужину для студентов колледжей Сайласа Крафт, который помогает организовывать ежегодный сбор средств для программы Образовательного фонда Ховардского муниципального колледжа (HCCEF). «Он выступал на 50-летнем юбилее моих родителей. Я ходил на собрания младших членов NAACP в его доме.

«Ни один черный в округе не знал имени Сайлас Крафт».

Хэш вышла на пенсию в 2016 году после карьеры в сфере кибербезопасности и работала волонтером в Центре афроамериканской культуры округа Ховард, когда кто-то спросил ее о работе в комитете Craft Dinner. «Конечно, мне было интересно», — говорит Хэш. «Это чествование компании Silas Craft, и это сделано по уважительной причине.

Выпускник Государственного университета Моргана и Университета Джона Хопкинса, Хэш имеет сестру, которая в 1980-х окончила медицинскую программу колледжа Ховарда.У нее также есть двоюродные братья и сестры, которые работают в школе. Это были ее единственные связи с HCC до того, как она присоединилась к комитету, но она была знакома со школой по своей предыдущей работе в окружной комиссии по правам человека.

«Мне нравится то, что делает HCC», — говорит она. «Они действительно любят разнообразие округа. Когда я впервые попал в университетский городок, я почувствовал, что принадлежу ему. Я провел много времени, изучая политику колледжа — как они тренируются и что делают с персоналом. Они выдающиеся в своей работе.”

Программа Silas Craft Collegians — это академическое сообщество, изучающее лидерство для недавних выпускников средней и средней школы. Хэш говорит, что они представляют собой сущность студентов, с которыми Крафт любил работать, тех, кто может быть не очень успешным вначале, но может быть отличным. Принять участие в такой программе несложно.

«Ужин проходит хорошо, и мы получаем большую поддержку сообщества», — говорит она. «Мы всегда достигаем нашей денежной цели по финансированию стипендий.Мы с мужем верим в необходимость возвращать деньги, особенно в программы для меньшинств и малообеспеченных лиц ».

Хэш был среди 50 учеников последнего выпускного класса Табменской средней школы (1965) до того, как уездные школы были разделены. Она работала на фундаменте, работая над восстановлением и открытием здания как Культурного центра Харриет Табман. «Это важный вклад в рассказывание истории нашего округа», — говорит Хэш.

Она рассматривает ГЦК в таком же свете.

«Это одно из учреждений, на которое вы можете легко указать и продемонстрировать, насколько округ верит в качество и инклюзивность», — говорит она.«Это одна из главных вещей, которую округ должен показать, и пример того, что округ может произвести с точки зрения совершенства».

Interledger: соглашения о временном блокировании (HTLA)

Обобщение контрактов с временной блокировкой хеширования (HTLC), используемых для защиты платежей Interledger.

Этот документ предполагает некоторое знакомство с HTLC и Interledger. В нем кратко описаны оба аспекта, но его лучше всего прочитать после IL-RFC 1: Interledger Architecture.

Interledger обеспечивает безопасные многоскачковые платежи с использованием условных переводов. Некоторые бухгалтерские книги изначально обеспечивают условные переводы с использованием контрактов с временной блокировкой хеширования (HTLC). Однако не все реестры поддерживают HTLC.

Соглашения о временной блокировке (HTLA) являются обобщением HTLC, которые могут быть реализованы для любого типа реестра, независимо от того, поддерживает ли реестр HTLC. HTLA работают с общедоступными и частными блокчейнами, централизованными реестрами, каналами платежей и даже с наличными деньгами или случаями, когда реестр отсутствует.Существует ряд типов HTLA, для которых требуются различные уровни функциональности реестра и двустороннего доверия. В этом документе описывается, как работают HTLA, и излагаются функции и компромиссы различных вариантов.

Примечание. Interledger-платежи могут одновременно безопасно проходить через несколько типов HTLA. Выбор типа HTLA — это строго двустороннее решение. Тип используемого HTLA не влияет на безопасность других участников пути. Подробнее об этом см. Interledger через различные HTLA.

Содержание

Справочная информация о контрактах с временной блокировкой хеширования (HTLC)
Соглашения о временной блокировке (HTLA)
HTLA без поддержки ригеля
Interledger через различные HTLAs
Спектр типов HTLA
1. Каналы условных платежей (с HTLC)
2. Хранение / условное депонирование во внутренней бухгалтерской книге (с использованием HTLC)
3. Простые каналы оплаты
4. Линии доверия
Приложение: Дополнительные типы HTLA

Справочная информация о контрактах с хешированной временной блокировкой (HTLC)

Контракт с временной блокировкой хеширования (HTLC) — это условный перевод, в котором условие выполняется регистром.Это концепция сообщества Биткойн, которая используется в сети Lightning.

Когда перевод «подготовлен», средства отправителя блокируются бухгалтерской книгой до выполнения заранее определенного условия. Условием является хэш-блок или дайджест криптографической хеш-функции, такой как SHA-256 в Lightning и Interledger. «Контракт» предусматривает, что получатель может потребовать средства, представив действительный прообраз хеш-дайджеста до истечения заданного тайм-аута. По истечении тайм-аута средства автоматически возвращаются отправителю.Это контракт на временную блокировку хеширования.

HTLC контролируются реестром, поэтому сторонам, совершающим транзакцию, нужно только доверять реестру для правильного выполнения контракта. Однако этот механизм требует поддержки реестра и работает только с реестрами, которые реализуют хэш-блокировки и тайм-ауты.

Interledger разработан для работы со всеми реестрами, поэтому он должен поддерживать как реестры с поддержкой хэшлоков и тайм-аутов, так и без них.

Соглашения о хешировании времени (HTLA)

Контракт — это определенный тип соглашения, исполнение которого обеспечивается третьей стороной.Соглашения о хешированной временной блокировке (HTLA) обобщают идею HTLC, чтобы включать соглашения, соблюдение которых обеспечивается реестром. Этот принцип используется в Interledger с момента запуска проекта, но термин HTLA был предложен совсем недавно в этой ветке списка рассылки Interledger.

HTLA обеспечивают безопасные платежи Interledger через все типы регистров, включая те, которые не поддерживают условные переводы.

HTLA без поддержки Ledger

Две стороны, использующие HTLA в реестре, не поддерживающем хэш-блоки и тайм-ауты, могут действовать следующим образом.Отправитель отправит получателю сообщение о том, что он хочет «подготовить» передачу с заданным хеш-блоком и тайм-аутом. Стороны соглашаются, что если получатель представляет прообраз хеша до истечения времени ожидания, перевод выполняется, и отправитель должен получателю деньги. Расчеты по долгам производятся с помощью простых переводов в бухгалтерскую книгу.

В случае соглашения с постфинансированием отправитель может урегулировать свою задолженность перед получателем либо для каждого платежа, если его бухгалтерская книга работает быстро и имеет низкие комиссии, либо после того, как общая сумма задолженности достигнет доверительного / кредитного лимита сторон.В этом случае получатель должен доверять отправителю в оплате своей задолженности. Риск можно ограничить, установив ограничение на сумму, которую отправитель может отправить до оплаты.

Для соглашений с предварительным финансированием отправитель переводит получателю либо сумму отдельного платежа, либо общую сумму. Затем получатель вычитает сумму каждого выполненного «условного перевода» из суммы предварительного финансирования. В этом случае отправитель должен доверять получателю, чтобы он не украл предварительно профинансированную сумму, но этот риск, очевидно, можно ограничить, ограничив предварительно профинансированную сумму.

Таким образом,

HTLA работают с реестрами, которые поддерживают хэш-блокировки и тайм-ауты (как HTLC), и с реестрами, которые этого не делают.

Дополнительные сведения о HTLA без поддержки реестра см. В разделах ниже, посвященных простым каналам оплаты и линиям доверия.

Interledger через разнообразные HTLAs

Один платеж Interledger может проходить через несколько различных типов HTLA. Протокол Interledger гарантирует, что безопасность каждого HTLA не зависит от других типов HTLA, используемых в пути.

Это критический момент для понимания HTLA и Interledger, поэтому мы будем использовать примерный поток, чтобы проиллюстрировать это.

Пример потока платежей

В этом исполнении классического платежа от Алисы к Бобу Алиса имеет учетную запись в цепочке блоков, которая реализует HTLC, а Боб имеет счет в банке, который не поддерживает HTLC:

  On-Ledger HTLC Payment Channel Trustline
Алиса - (Блокчейн A) -> Коннектор 1 - (Блокчейн B) -> Коннектор 2 - (Банк C) -> Боб

Каждый - (...) -> представляет другой тип HTLA, но все они используют один и тот же хэш-блок.

Поток протокола Interledger (подробно описанный ниже) гарантирует, что каждому участнику нужно заботиться только о тех HTLA, в которых он непосредственно участвует. Сбой на другом участке пути — или выбор, казалось бы, неразумного типа HTLA — не влияет на другие соглашения.

Поток платежей по протоколу Interledger:

Алиса и Боб согласовывают хэш-код H .Прообраз P известен только Бобу (и Алисе в случае PSK).
Алиса подготавливает перевод на Connector 1 , создавая и финансируя HTLC на Blockchain A с хеш-блоком H (см. Хранение / условное депонирование в бухгалтерской книге).
Коннектор 1 подготавливает перевод на Коннектор 2 через их общий платежный канал, также используя хэш-блок H (см. Простые каналы оплаты).
Коннектор 2 подготавливает передачу Бобу на их общей линии доверия с помощью Hashlock H (см. Линии доверия).
Если Боб создает прообраз P до тайм-аута передачи, соединитель 2 «заплатит» Бобу , увеличив его баланс на своей линии доверия.
Если Connector 2 отправляет P на Connector 1 до истечения времени их передачи, Connector 1 отправит подписанное требование на оплату Connector 2 .(Обратите внимание, что действительно ли это делает Connector 1 , это не имеет отношения к другим сторонам на пути. Connector 2 уже выплачен Bob , и это не может быть отменено. Connector 1 может отправить прообраз на Блокчейн A и по-прежнему отказываемся подавать иск на Connector 2 . Это известный и управляемый риск для Connector 2 , и никакие другие стороны не затронуты этим.)
Если Connector 1 отправит P на Blockchain A до истечения времени ожидания, передача будет выполнена, и Алиса получит подтверждение P , что Bob был оплачен.(Заметим еще раз, что то, правильно ли выполняется HTLC на блокчейне A , имеет значение только для Алиса и Connector 1 . Свойства бухгалтерской книги имеют значение только для сторон, имеющих счета в этой бухгалтерской книге.)

Один из способов подумать об этом: HTLA абстрагируются от того, что значит «получать деньги». Это просто соглашение между двумя сторонами, и никого больше не волнует, как оно устроено. Важно только то, что каждый человек доволен соглашениями, частью которых он является.Поскольку все хэш-блоки будут одинаковыми, либо все передачи произойдут, либо ни одна из них не будет (за исключением сбоя выполнения соединителя).

Для получения дополнительных сведений о наборе протоколов Interledger и безопасности см. IL-RFC 1: Архитектура Interledger.

Интернет «шляпа»: важность возможности интеграции любого типа сети была продемонстрирована RFC 1149: Стандарт для передачи дейтаграмм IP на Avian Carrier.

Спектр HTLA типов

Различные типы HTLA представляют собой компромисс между сложностью и риском.Чем больше функциональных возможностей предоставляет реестр, тем меньше пользователям этого реестра нужно доверять друг другу.

	Каналы условных платежей (с HTLC)	Хранение / условное депонирование в бухгалтерской книге (с использованием HTLC)	Простые каналы оплаты	Линии доверия
Требуется поддержка главной книги	Высокая	Высокая	Средний	Низкий
Сложность реализации	Высокая	Средний	Низкий	Низкий
Двусторонний риск	Низкий	Низкий	Средний	Высокая

Каналы условных платежей (с HTLC)

Ledger Необходимые функции: Платежные каналы с обновлениями HTLC
Требования к нефункциональной книге: Fast *
Деньги под угрозой: Нет
Примеры: Каналы в стиле Lightning *

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

Используя условные каналы оплаты, отправитель и получатель могут совершать транзакции без риска для каких-либо средств, потому что все споры будут разрешаться через бухгалтерскую книгу. Это можно использовать как механизм, позволяющий «через» регистрировать больший объем платежей, чем он может изначально поддерживать.

и аст; Примечание по скорости книги: Каналы условных платежей могут быть наиболее подходящими для быстрых регистров, потому что тайм-аут каждой передачи должен учитывать время обработки книги.Получатель полагается на тот факт, что он может выкупить свои средства даже в случае спора с отправителем, представив свои претензии и прообразы хеш-кода в реестре. Однако у отправителей и соединителей есть множество причин, по которым они хотят или требуют, чтобы платежи Interledger выполнялись или не выполнялись быстро (например, для повторных попыток и для снижения риска обменного курса). В результате каналы условных платежей могут работать с Interledger только в том случае, если бухгалтерская книга может обрабатывать заявки за несколько секунд или меньше.

Хранение / условное депонирование в бухгалтерской книге (с использованием HTLC)

Требуемые функции книги: переводов с HTLC
Требования к нефункциональной книге: Быстро, низкие комиссии, высокая пропускная способность
Деньги под угрозой: Нет
Примеры : Escrow Contract Ethereum, XRP Escrow

Если реестр обеспечивает поддержку HTLC и является достаточно быстрым и недорогим, участники могут отправлять все платежи Interledger непосредственно через реестр.Отправитель готовит условный перевод, помещая средства на удерживаемый счет в бухгалтерской книге в ожидании заданного хэш-кода и тайм-аута. Если получатель представляет прообраз хеша до истечения времени ожидания, бухгалтерская книга выполняет перевод и автоматически переводит средства на счет получателя. Если время ожидания истекло, бухгалтерская книга возвращает средства отправителю.

Использование условных переводов на основе бухгалтерской книги позволяет сторонам совершать транзакции без риска, но бухгалтерская книга должна быть способна обрабатывать большие объемы платежей быстро и с низкими комиссиями.

Простые каналы оплаты

Требуемые функции главной книги: Безусловные, однонаправленные каналы оплаты
Требования к нефункциональной книге: N / A
Деньги под угрозой: Всего подготовлено / выполнено без требований
Примеры: биткойн-каналов CLTV, XRP PayChan

Простые каналы оплаты позволяют сторонам отправлять больший объем платежей, чем бухгалтерская книга может обработать сама.Чтобы настроить простой однонаправленный платежный канал, отправитель помещает средства на временный счет в бухгалтерской книге, совместно используемой с получателем. Средства могут быть сняты из бухгалтерской книги только путем предъявления претензии, подписанной обеими сторонами, в которой указывается часть средств, которая будет переведена получателю, и сумма, которая будет возвращена отправителю. Отправитель фактически платит получателю, отправляя получателю подписанные претензии (а не бухгалтерскую книгу), которые дают получателю право снимать большую часть средств канала.

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

Соглашение между отправителем и получателем определяет порядок разрешения споров, включая случаи, когда получатель думает, что он отправил прообраз вовремя, а отправитель думает иначе.Обе стороны должны придерживаться своего мнения о тайм-ауте, а не перекладывать на другую сторону.

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

Функциональность, необходимая для простых каналов оплаты, сегодня присутствует практически во всех основных блокчейнах, включая Биткойн (даже без SegWit), Ethereum, XRP, Zcash и Chain.

Линии доверия

Требуемые функции книги: Переводы между счетами
Требования к нефункциональной книге: N / A
Деньги под угрозой: Общий баланс Trustline
Примеры: ilp-plugin-virtual

Если реестр не поддерживает Interledger, стороны по-прежнему могут подключаться к Interledger, используя линии доверия.Отправитель готовит перевод, отправляя получателю сообщение, включающее хэш-код и тайм-аут. Если получатель создает прообраз хеша до истечения времени ожидания, задолженность отправителя увеличивается на сумму перевода. Как и в случае с простыми каналами оплаты, участники должны договориться о том, как разрешать споры, в том числе разногласия по поводу того, был ли прообраз хеширован вовремя. Отправитель может продолжать отправлять платежи, пока они не достигнут максимального баланса, разрешенного получателем. В этот момент отправитель оплачивает свой баланс, делая перевод в бухгалтерской книге.

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

Примечательно, что линии доверия работают с любым типом «бухгалтерской книги», включая наличные деньги! Пока существует способ перевода средств между отправителем и получателем, они могут отправлять платежи Interledger и производить расчеты только при достижении лимита доверия. Если потоки платежей в обоих направлениях сбалансированы, может даже не возникнуть необходимость в расчетах.

Приложение: Дополнительные типы HTLA

Это приложение включает дополнительные типы HTLA, которые возможны, но не были упомянуты выше либо потому, что они менее желательны, либо еще не реализованы.

Условное депонирование третьей стороны

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

Желательно, чтобы в реестрах реализовывались удержания изначально, но этот тип HTLA может использоваться в тех случаях, когда это невозможно или не происходит. И отправитель, и получатель должны доверять поставщику условного депонирования полную стоимость каждого перевода либо из-за репутации, либо из-за юридических договоренностей. Если отправитель и получатель действительно доверяют друг другу до определенного предела, они могут избежать необходимости в третьей стороне, используя линии доверия.

Нотариально заверенные каналы оплаты

Споры могут возникать в HTLA на основе платежных каналов из-за разногласий по поводу тайм-аутов. Поскольку не существует единого источника достоверной информации о том, был ли прообраз хэшлока отправлен вовремя, асимметрия часов или сетевые задержки могут заставить получателя подумать, что передача должна быть выполнена, в то время как отправитель считает, что срок ее действия истек.

Чтобы снизить риск споров о тайм-аутах, отправитель и получатель могут договориться о привлечении стороннего нотариуса в качестве хронометриста.Отправитель готовит перевод, предоставляя реквизиты нотариусу и получателю (если нотариус также не выступает в качестве посредника сообщений). Получатель отправляет прообраз нотариусу, который устанавливает тайм-аут. Нотариус подписывает заявление, подтверждающее, был ли прообраз получен вовремя, и передает подписанное сообщение как отправителю, так и получателю.

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

Сторонние платежные каналы

Попадая между гарантиями условного депонирования третьей стороны и нотариально заверенных каналов оплаты, «сторонний платежный канал» включает в себя депонирование денег в платежном канале и предоставление третьей стороне полномочий для предъявления претензий.Чтобы настроить платежный канал, отправитель вносит средства на временный счет в бухгалтерской книге, как в простом платежном канале. Однако ключ третьей стороны уполномочен создавать заявки на баланс канала вместо использования открытого ключа отправителя.

Когда отправитель готовит перевод, он отправляет сообщение получателю, включая хэш-блокировку и тайм-аут. Для выполнения перевода получатель отправляет прообраз третьему лицу. Если третья сторона получает прообраз до истечения тайм-аута, она платит получателю из средств отправителя, подписывая новое требование.

В этой модели получателю вообще не нужно доверять отправителю. Вместо этого получатель доверяет третьей стороне, которая честно применяет тайм-ауты и подписывает заявки, когда прообразы отправляются вовремя. Это означает, что получателю необходимо доверять третьей стороне только те переводы, которые были выполнены, но еще не покрыты претензиями.

Отправитель должен доверять третьей стороне, чтобы она не предъявляла претензий на сумму, превышающую его задолженность, что означает, что они доверяют третьей стороне весь баланс платежного канала.Однако, если третье лицо не вступает в сговор с получателем, у него нет стимула выплачивать больше, чем должен отправитель.

4. Ключи, адреса, кошельки — освоение биткойнов [Книга]

Кошельки — это контейнеры для закрытых ключей, обычно реализованные в виде структурированных файлов или простых баз данных. Другой метод создания ключей — это детерминированная генерация ключей . Здесь вы получаете каждый новый закрытый ключ, используя одностороннюю хеш-функцию из предыдущего закрытого ключа, связывая их в последовательности.Пока вы можете воссоздать эту последовательность, вам понадобится только первый ключ (известный как начальный ключ или главный ключ ), чтобы сгенерировать их все. В этом разделе мы рассмотрим различные методы генерации ключей и построенные на их основе структуры кошелька.

Недетерминированные (случайные) кошельки

В первых биткойн-клиентах кошельки представляли собой просто набор случайно сгенерированных закрытых ключей. Этот тип кошелька называется недетерминированным кошельком Тип 0 .Например, клиент Bitcoin Core предварительно генерирует 100 случайных закрытых ключей при первом запуске и при необходимости генерирует дополнительные ключи, используя каждый ключ только один раз. Этот тип кошелька получил название «Just a Bunch Of Keys» или JBOK, и такие кошельки заменяются детерминированными кошельками, поскольку они громоздки в управлении, резервном копировании и импорте. Недостатком случайных ключей является то, что если вы генерируете много из них, вы должны хранить копии всех из них, а это означает, что кошелек необходимо часто создавать резервные копии.Для каждого ключа необходимо создать резервную копию, иначе средства, которые он контролирует, будут безвозвратно потеряны, если кошелек станет недоступен. Это напрямую противоречит принципу недопущения повторного использования адреса, когда каждый биткойн-адрес используется только для одной транзакции. Повторное использование адресов снижает конфиденциальность, связывая друг с другом несколько транзакций и адресов. Недетерминированный кошелек типа 0 — плохой выбор кошелька, особенно если вы хотите избежать повторного использования адреса, потому что это означает управление множеством ключей, что создает необходимость в частом резервном копировании.Хотя клиент Bitcoin Core включает кошелек Type-0, разработчики Bitcoin Core не рекомендуют использовать этот кошелек. На рис. 4-8 показан недетерминированный кошелек, содержащий беспорядочную коллекцию случайных ключей.

Детерминированные (засеянные) кошельки

Детерминированные, или «засеянные» кошельки — это кошельки, которые содержат закрытые ключи, которые все получены из общего начального числа посредством использования односторонней хеш-функции. Начальное число — это случайно сгенерированное число, которое комбинируется с другими данными, такими как порядковый номер или «цепной код» (см. Иерархические детерминированные кошельки (BIP0032 / BIP0044)) для получения закрытых ключей.В детерминированном кошельке начального числа достаточно для восстановления всех производных ключей, и поэтому достаточно одной резервной копии во время создания. Начального числа также достаточно для экспорта или импорта кошелька, что позволяет легко переносить все ключи пользователя между различными реализациями кошелька.

Рисунок 4-8. Недетерминированный (случайный) кошелек типа 0: набор случайно сгенерированных ключей

Мнемонические коды — это последовательности английских слов, которые представляют (кодируют) случайное число, используемое в качестве начального числа для получения детерминированного кошелька.Последовательности слов достаточно, чтобы воссоздать начальное число и оттуда воссоздать кошелек и все производные ключи. Приложение кошелька, которое реализует детерминированные кошельки с мнемоническим кодом, будет показывать пользователю последовательность из 12–24 слов при первом создании кошелька. Эта последовательность слов является резервной копией кошелька и может использоваться для восстановления и воссоздания всех ключей в том же или любом совместимом приложении кошелька. Мнемонические кодовые слова облегчают пользователям резервное копирование кошельков, поскольку их легко читать и правильно расшифровывать по сравнению со случайной последовательностью чисел.

Мнемонические коды определены в предложении по усовершенствованию биткойнов 39 (см. [Bip0039]), в настоящее время в статусе черновика. Обратите внимание, что BIP0039 — это черновик предложения, а не стандарт. В частности, существует другой стандарт с другим набором слов, который использовался кошельком Electrum до BIP0039. BIP0039 используется кошельком Trezor и несколькими другими кошельками, но несовместим с реализацией Electrum.

BIP0039 определяет создание мнемонического кода и начального числа следующим образом:

Создайте случайную последовательность (энтропию) от 128 до 256 бит.
Создайте контрольную сумму случайной последовательности, взяв несколько первых битов ее хэша SHA256.
Добавьте контрольную сумму в конец случайной последовательности.
Разделите последовательность на разделы по 11 бит, используя их для индексации словаря из 2048 предопределенных слов.
Произведите от 12 до 24 слов, представляющих мнемонический код.

Таблица 4-5 показывает взаимосвязь между размером данных энтропии и длиной мнемонических кодов в словах.

Таблица 4-5.Мнемонические коды: энтропия и длина слова

9304 9304 9304

Энтропия (биты)	Контрольная сумма (биты)	Энтропия + контрольная сумма	Длина слова
132	12
160	5	165	15	9306 9304	18
224	7	231	21
256 9300009

Мнемонический код представляет от 128 до 256 бит, которые используется для получения более длинного (512-битного) начального числа с помощью функции растяжения ключа PBKDF2.Полученное начальное число используется для создания детерминированного кошелька и всех его производных ключей.

В таблицах 4-6 и 4-7 показаны некоторые примеры мнемонических кодов и производимых ими семян.

Таблица 4-6. 128-битный мнемонический код энтропии и результирующее начальное число

Энтропийный ввод (128 бит)

0c1e24e59d297e14d45f14e1a1a1 9306

9306

0 9306

фургон защиты несут ревнивую истину мусор претензия echo media make crunch

Seed (512 бит)

3338a6d2ee71c7f28eb5b882159634cd46a898fa463e9d2d0980f8e 8a599b44b93187be6ee3ab5fd3ead7dd646341b2cdb8d08d13bf7

Таблица 4-7.256 битых энтропии мнемонического кода и полученное семя

энтропийных ввода данных (256 бит)	2041546864449caff939d32d574753fe684d3c947c3346713dd8423e74abcf8c
Мнемоника (24 слов)	торт яблоко заимствовать шелк одобрять фитнес топ отказ катушка бунт оставайся волк багаж кислород слабый серьезное изменение меры пригласить любовную ловушку поле дилемма обязать
семя (512 бит)	3972e432e99040f75ebe13a660110c3e29d131a2c808c747eeef1631d fce540af281bf7cdeade0dd2c1c795bd02f1e4049e205a0158906c343

Иерархические детерминированные кошельки (BIP0032 / BIP0044)

.Наиболее продвинутой формой детерминированных кошельков является иерархический детерминированный кошелек или HD кошелек , определенный стандартом BIP0032. Иерархические детерминированные кошельки содержат ключи, полученные в виде древовидной структуры, так что родительский ключ может выводить последовательность дочерних ключей, каждый из которых может выводить последовательность ключей внуков и так далее до бесконечной глубины. Эта древовидная структура проиллюстрирована на Рисунке 4-9.
Рисунок 4-9. Иерархический детерминированный кошелек типа 2: дерево ключей, сгенерированное из начального числа
Совет
Если вы реализуете биткойн-кошелек, он должен быть построен как кошелек HD в соответствии со стандартами BIP0032 и BIP0044.
Кошельки
HD имеют два основных преимущества перед случайными (недетерминированными) ключами. Во-первых, древовидная структура может использоваться для выражения дополнительного организационного значения, например, когда определенная ветвь подключей используется для приема входящих платежей, а другая ветвь используется для получения изменений от исходящих платежей. Ветви ключей также можно использовать в корпоративной среде, распределяя разные ветви по отделам, дочерним компаниям, определенным функциям или категориям бухгалтерского учета.
Второе преимущество кошельков HD заключается в том, что пользователи могут создавать последовательность открытых ключей, не имея доступа к соответствующим закрытым ключам.Это позволяет использовать кошельки HD на небезопасном сервере или в режиме только для приема, выдавая разные публичные ключи для каждой транзакции. Открытые ключи не нужно предварительно загружать или извлекать заранее, но на сервере нет закрытых ключей, на которые можно потратить средства.
Создание кошелька HD из начального числа
Кошельки HD создаются из одного корневого начального числа , которое является 128-, 256- или 512-битным случайным числом. Все остальное в HD-кошельке детерминированно получено из этого корневого семени, что позволяет воссоздать весь HD-кошелек из этого семенного материала в любом совместимом HD-кошельке.Это упрощает резервное копирование, восстановление, экспорт и импорт кошельков HD, содержащих тысячи или даже миллионы ключей, путем простого переноса только корневого начального числа. Корневое семя чаще всего представлено последовательностью мнемонических слов , как описано в предыдущем разделе Мнемонические кодовые слова, чтобы людям было легче его расшифровывать и сохранять.
Процесс создания мастер-ключей и мастер-кода цепочки для кошелька HD показан на Рисунке 4-10.
Рисунок 4-10. Создание мастер-ключей и кода цепочки из корневого начального числа
Корневое начальное значение вводится в алгоритм HMAC-SHA512, а полученный хэш используется для создания основного закрытого ключа (m) и основного кода цепочки .Главный закрытый ключ (m) затем генерирует соответствующий главный открытый ключ (M), используя обычный процесс умножения эллиптической кривой m * G , который мы видели ранее в этой главе. Цепной код используется для введения энтропии в функцию, которая создает дочерние ключи из родительских ключей, как мы увидим в следующем разделе.
Получение закрытых дочерних ключей
Иерархические детерминированные кошельки используют функцию получения дочерних ключей (CKD) для получения дочерних ключей из родительских ключей.
Функции деривации дочерних ключей основаны на односторонней хэш-функции, которая объединяет:
Родительский закрытый или открытый ключ (несжатый ключ ECDSA)
Начальное число, называемое цепным кодом (256 бит)
Порядковый номер (32 бита)
Цепной код используется для введения в процесс кажущихся случайными данных, так что индекса недостаточно для получения других дочерних ключей. Таким образом, наличие дочернего ключа не позволяет найти его братьев и сестер, если у вас также нет цепного кода.Начальное значение кода цепочки (в корне дерева) создается из случайных данных, а последующие коды цепочки получаются из каждого родительского кода цепочки.
Эти три элемента объединяются и хешируются для создания дочерних ключей следующим образом.
Родительский открытый ключ, код цепочки и номер индекса объединяются и хешируются с помощью алгоритма HMAC-SHA512 для получения 512-битного хеша. Полученный хеш делится на две половины. Правая половина 256 бит хеш-вывода становится цепным кодом для дочернего элемента.Левая половина 256 бит хеша и номер индекса добавляются к родительскому закрытому ключу для создания дочернего закрытого ключа. На рис. 4-11 мы видим, как это проиллюстрировано с индексом, равным 0, чтобы произвести 0-й (первый по индексу) дочерний элемент родителя.
Рисунок 4-11. Расширение родительского закрытого ключа для создания дочернего закрытого ключа
Изменение индекса позволяет нам расширить родительский и создать другие дочерние элементы в последовательности, например, Дочерний 0, Дочерний 1, Дочерний 2 и т. Д. Каждый родительский ключ может иметь 2 миллиард детских ключей.
Повторяя процесс на один уровень ниже по дереву, каждый дочерний элемент может, в свою очередь, стать родителем и создать своих собственных дочерних элементов в бесконечном количестве поколений.
Дочерние закрытые ключи неотличимы от недетерминированных (случайных) ключей. Поскольку функция деривации является односторонней функцией, дочерний ключ не может использоваться для поиска родительского ключа. Дочерний ключ также нельзя использовать для поиска братьев и сестер. Если у вас есть n _{-й дочерний элемент}, вы не можете найти его братьев и сестер, таких как n – 1 дочерний элемент или n + 1 дочерний элемент, или любые другие дочерние элементы, которые являются частью последовательности.Только родительский ключ и цепной код могут наследовать всех потомков. Без кода дочерней цепочки дочерний ключ также не может использоваться для получения каких-либо внуков. Вам нужен как дочерний закрытый ключ, так и код дочерней цепочки, чтобы начать новую ветвь и получить внуков.
Итак, для чего можно использовать дочерний закрытый ключ сам по себе? Его можно использовать для создания открытого ключа и адреса биткойнов. Затем его можно использовать для подписания транзакций, чтобы потратить все, что было уплачено на этот адрес.
Подсказка
Дочерний закрытый ключ, соответствующий открытый ключ и биткойн-адрес неотличимы от ключей и адресов, созданных случайным образом.Тот факт, что они являются частью последовательности, не виден за пределами функции кошелька HD, которая их создала. После создания они работают точно так же, как «обычные» ключи.
Как мы видели ранее, функцию получения ключей можно использовать для создания дочерних элементов на любом уровне дерева на основе трех входных данных: ключа, кода цепочки и индекса желаемого дочернего элемента. Два основных ингредиента — это ключ и код цепи, и вместе они называются расширенным ключом . Термин «расширенный ключ» также можно рассматривать как «расширяемый ключ», потому что такой ключ может использоваться для получения дочерних элементов.
Расширенные ключи хранятся и представляются просто как соединение 256-битного ключа и 256-битного кода цепочки в 512-битную последовательность. Есть два типа расширенных ключей. Расширенный закрытый ключ представляет собой комбинацию закрытого ключа и кода цепочки и может использоваться для получения дочерних закрытых ключей (а из них — дочерних открытых ключей). Расширенный открытый ключ — это открытый ключ и код цепочки, который можно использовать для создания дочерних открытых ключей, как описано в разделе «Создание открытого ключа».
Думайте о расширенном ключе как о корне ветви в древовидной структуре кошелька HD.Из корня ветви вы можете получить остальную часть ветви. Расширенный закрытый ключ может создавать полную ветвь, тогда как расширенный открытый ключ может создавать только ветвь открытых ключей.
Совет
Расширенный ключ состоит из частного или открытого ключа и кода цепочки. Расширенный ключ может создавать дочерние элементы, генерируя свою собственную ветвь в древовидной структуре. Совместное использование расширенного ключа дает доступ ко всей ветке.
Расширенные ключи кодируются с помощью Base58Check, чтобы легко экспортировать и импортировать между различными кошельками, совместимыми с BIP0032.Кодировка Base58Check для расширенных ключей использует специальный номер версии, который приводит к префиксу «xprv» и «xpub» при кодировании в символах Base58, чтобы сделать их легко узнаваемыми. Поскольку расширенный ключ составляет 512 или 513 бит, он также намного длиннее, чем другие строки в кодировке Base58Check, которые мы видели ранее.
Вот пример расширенного секретного ключа, зашифрованного в Base58Check:
xprv9tyUQV64JT5qs3RSTJkXCWKMyUgoQp7F3hA1xzG6ZGu6u6Q9VMNjGr67Lctvy5P8oyaYAL9CAWrUE9i6GoNMKUga5biW6Hx4tws2six3b9c
Вот соответствующий расширенный открытый ключ, также закодированы в Base58Check:
xpub67xpozcx8pe95XVuZLHXZeG6XWXHpGq6Qv5cmNfi7cS5mtjJ2tgypeQbBs2UAR6KECeeMVKZBPLrtJunSDMstweyLXhRgPxdp14sk9tJPW9
Открытый ребенка ключ деривации
Как уже упоминалось ранее, очень полезной характеристикой иерархических детерминированных кошельков является способность извлекать открытые дочерние ключи из открытых родительских ключей, без , имеющих закрытые ключи.Это дает нам два способа получить дочерний открытый ключ: либо из дочернего закрытого ключа, либо непосредственно из родительского открытого ключа.
Таким образом, можно использовать расширенный открытый ключ для получения всех открытых ключей (и только открытых ключей) в этой ветви структуры кошелька HD.
Этот ярлык можно использовать для создания очень безопасных развертываний только с открытым ключом, где сервер или приложение имеет копию расширенного открытого ключа и не имеет каких-либо закрытых ключей. Такое развертывание может создать бесконечное количество открытых ключей и адресов биткойнов, но не может потратить деньги, отправленные на эти адреса.Между тем, на другом, более безопасном сервере, расширенный закрытый ключ может извлекать все соответствующие закрытые ключи для подписи транзакций и тратить деньги.
Одно из распространенных применений этого решения — установка расширенного открытого ключа на веб-сервере, который обслуживает приложение электронной коммерции. Веб-сервер может использовать функцию получения открытого ключа для создания нового адреса биткойнов для каждой транзакции (например, для корзины покупателя). На веб-сервере не будет закрытых ключей, уязвимых для кражи.Без кошельков HD единственный способ сделать это — создать тысячи адресов биткойнов на отдельном защищенном сервере, а затем предварительно загрузить их на сервер электронной коммерции. Такой подход громоздок и требует постоянного обслуживания, чтобы на сервере электронной торговли не «закончились» ключи.
Другое распространенное применение этого решения — холодное хранение или аппаратные кошельки. В этом сценарии расширенный закрытый ключ может храниться в бумажном кошельке или аппаратном устройстве (например, аппаратном кошельке Trezor), в то время как расширенный открытый ключ может храниться в сети.Пользователь может по желанию создавать «принимающие» адреса, в то время как закрытые ключи надежно хранятся в автономном режиме. Чтобы потратить средства, пользователь может использовать расширенный закрытый ключ на автономном подписывающем биткойн-клиенте или подписывать транзакции на устройстве аппаратного кошелька (например, Trezor). На рис. 4-12 показан механизм расширения родительского открытого ключа для получения дочерних открытых ключей.
Рисунок 4-12. Расширение родительского открытого ключа для создания дочернего открытого ключа
Создание защищенного дочернего ключа
Возможность получить ветвь открытых ключей из расширенного открытого ключа очень полезна, но сопряжена с потенциальным риском.Доступ к расширенному публичному ключу не дает доступа к дочерним частным ключам. Однако, поскольку расширенный открытый ключ содержит код цепочки, если закрытый дочерний ключ известен или каким-то образом просочился, его можно использовать с кодом цепочки для получения всех других закрытых дочерних ключей. Единственный утечка закрытого дочернего ключа вместе с кодом родительской цепочки раскрывает все закрытые ключи всех дочерних элементов. Хуже того, дочерний закрытый ключ вместе с кодом родительской цепочки можно использовать для вывода родительского закрытого ключа.
Чтобы противостоять этому риску, кошельки HD используют альтернативную функцию деривации, называемую усиленной деривацией , которая «разрывает» связь между родительским открытым ключом и кодом дочерней цепочки. Функция усиленного вывода использует родительский закрытый ключ для получения дочернего кода цепочки вместо родительского открытого ключа. Это создает «брандмауэр» в последовательности родитель / потомок с кодом цепочки, который нельзя использовать для компрометации закрытого ключа родителя или брата. Функция усиленного деривации выглядит почти идентично обычной деривации закрытого дочернего ключа, за исключением того, что родительский закрытый ключ используется в качестве входных данных для хэш-функции вместо родительского открытого ключа, как показано на диаграмме на рис. 4-13.
Рисунок 4-13. Усиленное получение дочернего ключа; опускает родительский открытый ключ
При использовании усиленной частной функции деривации результирующий дочерний частный ключ и код цепочки полностью отличаются от того, что было бы в результате обычной деривационной функции. Результирующая «ветвь» ключей может использоваться для создания расширенных открытых ключей, которые не являются уязвимыми, потому что код цепочки, который они содержат, не может быть использован для раскрытия каких-либо закрытых ключей. Таким образом, усиленная деривация используется для создания «пробела» в дереве над уровнем, на котором используются расширенные открытые ключи.
Проще говоря, если вы хотите использовать удобство расширенного открытого ключа для получения ветвей открытых ключей, не подвергая себя риску утечки кода цепочки, вам следует получить его от надежного родителя, а не от обычного родитель. Рекомендуется, чтобы дочерние элементы уровня 1 мастер-ключей всегда получали через усиленную деривацию, чтобы предотвратить компрометацию мастер-ключей.
Порядковые номера для нормального и усиленного вывода
Порядковый номер, используемый в функции вывода, является 32-битным целым числом.Чтобы легко отличить ключи, полученные с помощью обычной функции деривации, от ключей, полученных с помощью усиленной деривации, этот номер индекса разделен на два диапазона. Номера индексов от 0 до 2 ³¹ –1 (от 0x0 до 0x7FFFFFFF) используются только для нормального вывода. Номера индексов от 2 ³¹ до 2 ³² –1 (от 0x80000000 до 0xFFFFFFFF) используются только для усиленного вывода. Следовательно, если номер индекса меньше 2 ³¹, это означает, что дочерний элемент является нормальным, тогда как если номер индекса равен или больше 2 ³¹, дочерний элемент закреплен.
Чтобы упростить чтение и отображение порядкового номера, порядковый номер для защищенных потомков отображается, начиная с нуля, но со штрихом. Поэтому первый нормальный дочерний ключ отображается как 0, тогда как первый защищенный дочерний ключ (индекс 0x80000000) отображается как 0 ‘. Затем второй усиленный ключ будет иметь индекс 0x80000001 и отображаться как 1 ‘и так далее. Когда вы видите индекс кошелька HD i ‘, это означает 2 ³¹ + i.
Идентификатор ключа HD-кошелька (путь)
Ключи в HD-кошельке идентифицируются с использованием соглашения об именовании «пути», при этом каждый уровень дерева разделяется косой чертой (/) (см. Таблицу 4-8).Закрытые ключи, полученные из главного закрытого ключа, начинаются с буквы «m». Открытые ключи, полученные из главного открытого ключа, начинаются с буквы «M». Следовательно, первый закрытый дочерний ключ главного закрытого ключа — это m / 0. Первый дочерний открытый ключ — M / 0. Второй внук первого ребенка — m / 0/1 и так далее.
«Родословная» ключа читается справа налево, пока вы не дойдете до главного ключа, из которого он был получен. Например, идентификатор m / x / y / z описывает ключ, который является z-м дочерним элементом ключа m / x / y, который является y-м дочерним элементом ключа m / x, который является x-м дочерним элементом м.
Таблица 4-8. Примеры пути кошелька HD
Путь HD Описанный ключ
m / 0
Первый (0) дочерний закрытый ключ из главного ключа (m)
m / 0/0
Первый закрытый ключ внука первого ребенка (m / 0)
m / 0 ‘/ 0
Первый нормальный внук первый закаленный дочерний (м / 0 ‘)
м / 1/0
Первый закрытый ключ внука второго ребенка (м / 1)
M / 23 / 17/0/0
Первый праправнук открытый ключ первого правнука 18-го внука 24-го ребенка
Навигация по древовидной структуре кошелька HD
HD кошелек древовидная структура предлагает огромную гибкость.Каждый родительский расширенный ключ может иметь 4 миллиарда детей: 2 миллиарда нормальных детей и 2 миллиарда закаленных детей. У каждого из этих детей может быть еще 4 миллиарда детей и так далее. Дерево может быть сколь угодно глубоким, с бесконечным числом поколений. Однако при всей этой гибкости ориентироваться в этом бесконечном дереве становится довольно сложно. Особенно сложно переносить HD-кошельки между реализациями, потому что возможности внутренней организации в филиалы и подотрасли безграничны.
Два предложения по улучшению биткойнов (BIP) предлагают решение этой сложности путем создания некоторых предлагаемых стандартов для структуры деревьев кошельков HD. BIP0043 предлагает использовать первый усиленный дочерний индекс в качестве специального идентификатора, который обозначает «цель» древовидной структуры. Согласно BIP0043, кошелек HD должен использовать только одну ветвь 1-го уровня дерева с номером индекса, определяющим структуру и пространство имен остальной части дерева, определяя его назначение. Например, кошелек HD, использующий только ветку m / i ‘/, предназначен для обозначения определенной цели, и эта цель обозначена индексным номером «i».
Расширяя эту спецификацию, BIP0044 предлагает структуру с несколькими учетными записями в качестве «целевого» номера 44 ' под BIP0043. Все кошельки HD, следующие за структурой BIP0044, идентифицируются по тому факту, что они использовали только одну ветвь дерева: m / 44 ‘/.
BIP0044 определяет структуру как состоящую из пяти предопределенных уровней дерева:
m / цель '/ coin_type' / account '/ change / address_index
«Цель» первого уровня всегда устанавливается на 44' .Второй уровень «coin_type» указывает тип криптовалютной монеты, что позволяет использовать мультивалютные кошельки HD, где каждая валюта имеет собственное поддерево на втором уровне. На данный момент определены три валюты: биткойн — m / 44 ‘/ 0’, биткойн-тестовая сеть — m / 44 ‘/ 1’; а Litecoin — m / 44 ‘/ 2’.
Третий уровень дерева — «учетная запись», который позволяет пользователям разделить свои кошельки на отдельные логические вспомогательные учетные записи для бухгалтерских или организационных целей. Например, кошелек HD может содержать две «учетные записи» биткойнов: m / 44 ‘/ 0’ / 0 ‘и m / 44’ / 0 ‘/ 1’.Каждая учетная запись является корнем своего собственного поддерева.
На четвертом уровне, «изменение», кошелек HD имеет два поддерева: одно для создания адресов получения, а другое — для создания адресов изменений. Обратите внимание, что в то время как на предыдущих уровнях использовалась усиленная деривация, на этом уровне используется нормальная деривация. Это позволяет этому уровню дерева экспортировать расширенные открытые ключи для использования в незащищенной среде. Используемые адреса выводятся кошельком HD как дочерние элементы четвертого уровня, что делает пятый уровень дерева «address_index.Например, третий адрес приема для платежей в биткойнах на основном счете будет M / 44 ‘/ 0’ / 0 ‘/ 0/2. Таблица 4-9 показывает еще несколько примеров.
Таблица 4-9. BIP0044 Примеры структуры кошелька HD
Путь HD Описание ключа
M / 44 ‘/ 0’ / 0 ‘/ 0/2
Третий принимающий открытый ключ для основного счета биткойнов
M / 44 ‘/ 0’ / 3 ‘/ 1/14
Пятнадцатый открытый ключ смены адреса для четвертого счета биткойнов
м / 44 ‘/ 2’ / 0 ‘/ 0/1
Второй закрытый ключ в основной учетной записи Litecoin для подписи транзакций
Эксперименты с кошельками HD с использованием инструментов sx
Использование командной строки инструмент sx , представленный в главе 3, вы можете экспериментировать с генерацией и расширением детерминированных ключей BIP0032, а также отображать их в разных форматах:
$ sx hd-seed> m # создать новый главный частный ключ от seed и сохранить в файле "m" $ cat m # показать главный расширенный закрытый ключ xprv9s21ZrQh243K38iQ9Y5p6qoB8C75TE71NfpyQPdfGvzghDt39DHPFpovvtWZaRgY5uPwV7RpEgHs7cvdgfiSjLjjbuGKGcjRyU7RGGSS8Xa $ кот м | sx hd-pub 0 # генерировать расширенный открытый ключ M / 0 xpub67xpozcx8pe95XVuZLHXZeG6XWXHpGq6Qv5cmNfi7cS5mtjJ2tgypeQbBs2UAR6KECeeMVKZBPLrtJunSDMstweyLXhRgPxdp14sk9tJPW9 $ кот м | sx hd-priv 0 # сгенерировать расширенный закрытый ключ m / 0 xprv9tyUQV64JT5qs3RSTJkXCWKMyUgoQp7F3hA1xzG6ZGu6u6Q9VMNjGr67Lctvy5P8oyaYAL9CAWrUE9i6GoNMKUga5biW6Hx4tws2six3b9c $ кот м | sx hd-priv 0 | sx hd-to-wif # показать закрытый ключ m / 0 как WIF L1pbvV86crAGoDzqmgY85xURkz3c435Z9nirMt52UbnGjYMzKBUN $ кот м | sx hd-pub 0 | sx hd-to-address # показать биткойн-адрес M / 0 1CHCnCjgMNb6digimckNQ6TBVcTWBAmPHK $ кот м | sx hd-priv 0 | sx hd-priv 12 - жесткий | sx hd-priv 4 # генерировать m / 0/12 '/ 4 xprv9yL8ndfdPVeDWJenF18oiHguRUj8jHmVrqqD97YQHeTcR3LCeh53q5PXPkLsy2kRaqgwoS6YZBLatRZRyUeAkRPe1kLR1P6Mn7jt 9016Fqu00 900U.Транзакции - Освоение биткойнов [Книга]
Транзакции - самая важная часть системы биткойнов. Все остальное в биткойне предназначено для обеспечения того, чтобы транзакции можно было создавать, распространять в сети, проверять и, наконец, добавлять в глобальный реестр транзакций (блокчейн). Транзакции - это структуры данных, которые кодируют передачу стоимости между участниками системы биткойнов. Каждая транзакция является публичной записью в блокчейне биткойна, глобальной бухгалтерской книге с двойной записью.

В этой главе мы рассмотрим все различные формы транзакций, что они содержат, как их создавать, как они проверяются и как они становятся частью постоянной записи всех транзакций.

Жизненный цикл транзакции начинается с создания транзакции, также известного как происхождение . Затем транзакция подписывается одной или несколькими подписями, указывающими на разрешение расходовать средства, указанные в транзакции. Затем транзакция транслируется в сети биткойнов, где каждый сетевой узел (участник) проверяет и распространяет транзакцию, пока она не достигнет (почти) каждого узла в сети.Наконец, транзакция проверяется майнинговым узлом и включается в блок транзакций, который записывается в цепочке блоков.

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

В некотором смысле это помогает думать о транзакции так же, как о бумажном чеке. Как и чек, транзакция - это инструмент, который выражает намерение перевести деньги и не виден финансовой системе до тех пор, пока не будет отправлен на исполнение. Как и в случае с чеком, отправитель транзакции не обязательно должен подписывать транзакцию.

Транзакции может создавать кто угодно онлайн или офлайн, даже если лицо, создающее транзакцию, не является авторизованным лицом, подписывающим учетную запись.Например, клерк по счетам к оплате может обрабатывать чеки к оплате на подпись генеральным директором. Точно так же клерк по счетам к оплате может создавать биткойн-транзакции, а затем заставлять генерального директора применять цифровые подписи, чтобы сделать их действительными. В то время как чек ссылается на конкретную учетную запись как на источник средств, биткойн-транзакция ссылается на конкретную предыдущую транзакцию в качестве источника, а не на учетную запись.

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

Трансляция транзакций в сеть биткойнов

Во-первых, транзакция должна быть доставлена в сеть биткойнов, чтобы ее можно было распространить и включить в цепочку блоков.По сути, биткойн-транзакция - это всего лишь от 300 до 400 байтов данных и должна достигнуть любого из десятков тысяч биткойн-узлов. Отправителям не нужно доверять узлам, которые они используют для широковещательной рассылки транзакции, если они используют более одного, чтобы гарантировать ее распространение. Узлам не нужно доверять отправителю или устанавливать «личность» отправителя. Поскольку транзакция подписана и не содержит конфиденциальной информации, закрытых ключей или учетных данных, ее можно публично транслировать с использованием любого удобного базового сетевого транспорта.В отличие, например, от транзакций по кредитным картам, которые содержат конфиденциальную информацию и могут быть переданы только в зашифрованных сетях, транзакция с биткойнами может быть отправлена по любой сети. Пока транзакция может достичь узла биткойнов, который распространит ее в сеть биткойнов, не имеет значения, как она передается на первый узел.

Биткойн-транзакции могут быть переданы в биткойн-сеть через небезопасные сети, такие как WiFi, Bluetooth, NFC, Chirp, штрих-коды или путем копирования и вставки в веб-форму.В крайних случаях транзакция биткойнов может быть передана по пакетной радиосвязи, спутниковой ретрансляции или коротковолновой передаче с использованием пакетной передачи, расширенного спектра или скачкообразной перестройки частоты, чтобы избежать обнаружения и глушения. Биткойн-транзакцию можно даже закодировать в виде смайлов (смайликов) и опубликовать на общедоступном форуме или отправить в виде текстового сообщения или сообщения в чате Skype. Биткойн превратил деньги в структуру данных, что сделало практически невозможным остановить кого-либо от создания и выполнения транзакции с биткойнами.

Распространение транзакций в сети биткойнов

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

Биткойн-сеть является одноранговой сетью, что означает, что каждый биткойн-узел подключен к нескольким другим биткойн-узлам, которые он обнаруживает во время запуска через одноранговый протокол. Вся сеть образует слабо связанную сетку без фиксированной топологии или какой-либо структуры, что делает все узлы равноправными.Сообщения, включая транзакции и блоки, распространяются от каждого узла к одноранговым узлам, к которым он подключен. Новая подтвержденная транзакция, введенная в любой узел сети, будет отправлена трем-четырем соседним узлам, каждый из которых отправит ее еще трем-четырем узлам и т. Д. Таким образом, в течение нескольких секунд действительная транзакция будет распространяться в виде экспоненциально растущей ряби по сети, пока все подключенные узлы не получат ее.

Биткойн-сеть предназначена для распространения транзакций и блоков на все узлы эффективным и отказоустойчивым способом, устойчивым к атакам.Чтобы предотвратить рассылку спама, атаки типа «отказ в обслуживании» или другие неприятные атаки на систему биткойнов, каждый узел независимо проверяет каждую транзакцию перед ее дальнейшим распространением. Деформированная транзакция не выйдет за пределы одного узла. Правила, по которым проверяются транзакции, более подробно описаны в разделе «Независимая проверка транзакций».

Транзакция - это структура данных , которая кодирует перевод стоимости из источника средств, называемый входом , в пункт назначения, называемый выходом .Входы и выходы транзакций не связаны с учетными записями или личностями. Вместо этого вы должны думать о них как о количестве биткойнов - фрагментах биткойнов, заблокированных определенным секретом, который может разблокировать только владелец или человек, который знает секрет. Транзакция содержит ряд полей, как показано в Таблице 5-1.

Таблица 5-1. Структура транзакции
, которая соответствует
Одна или несколько транзакций 4 байта

Размер Поле Описание

4 байта

Транзакция

1–9 байт (VarInt)

Счетчик входов

Сколько входов включено

Переменная

Входы

02
06

02 Один или несколько входов
1–9 байтов (VarInt)

Счетчик выходов

Сколько выходов включено

Переменная

Выходы

Lockt ime

Временная метка Unix или номер блока

Выходы и входы транзакций

Основным строительным блоком биткойн-транзакции является неизрасходованный выход транзакции или UTXO.UTXO - это неделимые блоки биткойн-валюты, привязанные к определенному владельцу, записанные в цепочке блоков и распознаваемые как денежные единицы всей сетью. Сеть биткойнов отслеживает все доступные (неизрасходованные) UTXO, которые в настоящее время исчисляются миллионами. Всякий раз, когда пользователь получает биткойн, эта сумма записывается в цепочке блоков как UTXO. Таким образом, биткойн пользователя может быть разбросан как UTXO среди сотен транзакций и сотен блоков. По сути, не существует такой вещи, как сохраненный баланс биткойн-адреса или учетной записи; есть только разрозненные UTXO, привязанные к конкретным владельцам.Концепция баланса биткойнов пользователя - это производная конструкция, созданная приложением кошелька. Кошелек рассчитывает баланс пользователя, сканируя цепочку блоков и собирая все UTXO, принадлежащие этому пользователю.

Совет

Нет счетов или остатков в биткойнах; есть только неизрасходованных выходов транзакций (UTXO), разбросанных по блокчейну.

UTXO может иметь произвольное значение, кратное сатоши. Точно так же, как доллары можно разделить до двух знаков после запятой как центы, биткойны можно разделить до восьми знаков после запятой как сатоши.Хотя UTXO может иметь любое произвольное значение, однажды созданное оно неделимо, как монета, которую нельзя разрезать пополам. Если UTXO больше, чем желаемое значение транзакции, он все равно должен быть использован полностью, и в транзакции должны быть сгенерированы изменения. Другими словами, если у вас есть 20 биткойнов UTXO и вы хотите заплатить 1 биткойн, ваша транзакция должна потреблять все 20 биткойнов UTXO и давать два результата: один платит 1 биткойн желаемому получателю, а другой платит 19 биткойнов в обмен на ваш кошелек.В результате большинство транзакций с биткойнами приведет к изменениям.

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

Аналогичным образом, биткойн-транзакция должна быть создана из UTXO пользователя в любых номиналах, доступных пользователю. Пользователи не могут разрезать UTXO вдвое больше, чем они могут разрезать долларовую купюру пополам и использовать ее в качестве валюты. Приложение кошелька пользователя обычно выбирает из доступных пользователю UTXO различные единицы, чтобы составить сумму, большую или равную желаемой сумме транзакции.

Как и в реальной жизни, биткойн-приложение может использовать несколько стратегий для удовлетворения суммы покупки: объединение нескольких меньших единиц, поиск точного изменения или использование одной единицы, превышающей стоимость транзакции, и внесение изменений. Вся эта сложная сборка расходуемого UTXO выполняется кошельком пользователя автоматически и невидима для пользователей. Это актуально только в том случае, если вы программно создаете необработанные транзакции из UTXO.

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

Исключением из цепочки вывода и ввода является специальный тип транзакции, называемый транзакцией coinbase , которая является первой транзакцией в каждом блоке. Эта транзакция размещается там «победившим» майнером и создает совершенно новый биткойн, подлежащий выплате этому майнеру в качестве вознаграждения за майнинг.Вот как создается денежная масса биткойна в процессе майнинга, как мы увидим в главе 8.

Подсказка

Что первично? Входы или выходы, курица или яйцо? Строго говоря, выходы на первом месте, потому что транзакции на базе монет, которые генерируют новый биткойн, не имеют входных данных и создают выходы из ничего.

Каждая биткойн-транзакция создает выходные данные, которые записываются в регистр биткойнов. Почти все эти выходы, за одним исключением (см. Выход данных (OP_RETURN)), создают расходуемые блоки биткойна, называемые неизрасходованные выходы транзакций или UTXO, которые затем распознаются всей сетью и доступны для владельца для использования в будущей транзакции. .Отправка кому-либо биткойнов создает неизрасходованный выход транзакции (UTXO), зарегистрированный на их адрес и доступный для использования.

UTXO отслеживаются каждым биткойн-клиентом с полным узлом в базе данных, хранящейся в памяти, называемой набором UTXO или пулом UTXO . Новые транзакции потребляют (расходуют) один или несколько из этих выходов из набора UTXO.

Выходы транзакции состоят из двух частей:

Количество биткойнов, выраженное в сатоши , наименьшая единица биткойнов.

Сценарий блокировки , также известный как «обременение», который «блокирует» эту сумму, указывая условия, которые должны быть выполнены, чтобы потратить выходные данные.

Язык сценариев транзакций, используемый в сценарии блокировки, упомянутом ранее, подробно обсуждается в разделах "Сценарии транзакций и язык сценариев".Таблица 5-2 показывает структуру вывода транзакции.

Таблица 5-2. Структура вывода транзакции

Размер Поле Описание

8 байт

Сумма
сат. биткойн)

1-9 байтов (VarInt)

Размер сценария блокировки

Длина сценария блокировки в байтах, в соответствии с

9309 Переменная Сценарий

Сценарий, определяющий условия, необходимые для расходования вывода

В примере 5-1 мы используем цепочку блоков.info API для поиска неизрасходованных выходов (UTXO) определенного адреса.

Пример 5-1. Скрипт, который вызывает API blockchain.info для поиска UTXO, связанного с адресом

# получение неизрасходованных выходных данных из API блокчейна импорт json импорт запросов # пример адреса адрес = '1Dorian4RoXcnBv9hnQ4Y2C1an6NJ4UrjX' # URL-адрес API: https://blockchain.info/unspent?active=
# Возвращает объект JSON со списком "unspent_outputs", содержащим UTXO, например: # {"unspent_outputs": [ # { # "tx_hash": "ebadfaa92f1fd29e2fe296eda702c48bd11ffd52313e986e99ddad 62167", # "tx_index": 517, # "tx_output_n": 1, # "script": "76a9148c7e252f8d64b0b6e3139850fcfefcf4a2d88ac", # "значение": 8000000, # "value_hex": "7a1200", # "подтверждения": 28691 #}, #... #]} или = запросов . получить ( 'https://blockchain.info/unspent?active= % s ' % адрес ) utxo_set = json . загружает ( или . текст ) [ "unspent_outputs" ] для utxo дюйм utxo_set : печать " % s : % d - % ld Satoshis" % ( utxo ' ' ' utxo [ 'tx_output_n' ], utxo [ 'value' ])
Запустив скрипт, мы видим список идентификаторов транзакций, двоеточие, номер индекса конкретный неизрасходованный выход транзакции (UTXO) и значение этого UTXO в сатоши.Сценарий блокировки не показан в выходных данных примера 5-2.
Пример 5-2. Запуск сценария get-utxo.py
$ python get-utxo.py ebadfaa92f1fd29e2fe296eda702c48bd11ffd52313e986e99ddad
62167: 1 - 8000000 сатоши 6596fd070679de96e405d52b51b8e1d644029108ec4cbfe451454486796a1ecf: 0 - 16050000 сатоши 74d788804e2aae10891d72753d1520da1206e6f4f20481cc1555b7f2cb44aca0: 0 - 5000000 Сатоши b2affea89ff82557c60d635a2a3137b8f88f12ecec85082f7d0a1f82ee203ac4: 0 - 10000000 сатоши ...
Условия расходов (обременения)
Выходные данные транзакции связывают определенную сумму (в сатоши) с конкретным обременением или сценарием блокировки, который определяет условие, которое должно быть выполнено, чтобы потратить эту сумму. В большинстве случаев сценарий блокировки блокирует вывод на конкретный биткойн-адрес, тем самым передавая право собственности на эту сумму новому владельцу. Когда Алиса заплатила Bob’s Cafe за чашку кофе, ее транзакция привела к получению 0,015 биткойнов на выходе , обремененных или привязанных к биткойн-адресу кафе.Эти 0,015 биткойнов были записаны в блокчейне и стали частью набора неизрасходованных транзакций, то есть отображались в кошельке Боба как часть доступного баланса. Когда Боб решает потратить эту сумму, его транзакция снимает обременение, разблокируя выход, предоставляя сценарий разблокировки, содержащий подпись из закрытого ключа Боба.
Проще говоря, входные данные транзакции - это указатели на UTXO. Они указывают на конкретный UTXO по ссылке на хэш транзакции и порядковый номер, где UTXO записывается в цепочке блоков.Чтобы потратить UTXO, вход транзакции также включает скрипты разблокировки, которые удовлетворяют условиям расходов, установленным UTXO. Сценарий разблокировки обычно представляет собой подпись, подтверждающую право собственности на биткойн-адрес, указанный в сценарии блокировки.
Когда пользователи производят платеж, их кошелек создает транзакцию, выбирая из доступного UTXO. Например, для совершения платежа в биткойнах 0,015 приложение кошелька может выбрать UTXO 0,01 и UTXO 0,005, используя их оба для добавления к желаемой сумме платежа.
В примере 5-3 мы показываем использование «жадного» алгоритма для выбора из доступных UTXO, чтобы произвести определенную сумму платежа. В этом примере доступный UTXO предоставляется как постоянный массив, но на самом деле доступный UTXO будет извлекаться с помощью вызова RPC к Bitcoin Core или к стороннему API, как показано в Примере 5-1.
Пример 5-3. Скрипт для расчета общего количества выпущенных биткойнов
# Выбирает выходные данные из списка UTXO с использованием жадного алгоритма. из sys импорт argv класс OutputInfo : def __init__ ( self , tx_hash , tx_index , значение ): сам . tx_hash = tx_hash сам . tx_index = tx_index сам . значение = значение def __repr__ ( self ): возврат "< % s : % s с % s Satoshis>" % ( self . . . tx_index , сам . значение ) # Выбрать оптимальные выходы для отправки из списка неизрасходованных выходов. # Возвращает список вывода и оставшееся изменение для отправки на # изменить адрес. def select_outputs_greedy ( неизрасходовано , min_value ): # Ошибка, если пусто. если нет неизрасходовано : возврат Нет # Разделение на 2 списка. лессеры = [ utxo для utxo in неизрасходованные if utxo . значение < min_value ] больше = [ utxo для utxo in неизрасходовано if utxo . значение > = min_value ] key_func = лямбда utxo : utxo . значение если больше : # Не пусто. Найдите наименьшее большее. min_greater = min ( больше ) изменить = min_greater . значение - min_value возврат [ min_greater ], изменение # Не найдено в лучших.Вместо этого попробуйте несколько лессеров. # Переставьте их в порядке убывания. Мы хотим использовать минимум # Максимальное количество входов. лессеры . сортировка ( ключ = key_func , обратный = True ) результат = [] накопитель = 0 для utxo в lessers : счет . добавить ( utxo ) аккумулятор + = utxo . значение если накопление > = min_value : изменить = накопить - min_value возврат результат , "Изменение: % d Satoshis" % изменение # Ничего не найдено. возврат Нет , 0 по умолчанию основной (): неизрасходованные = [ OutputInfo ( "ebadfaa92f1fd29e2fe296eda702c48bd11ffd52313e986e99ddad 62167" , 1 , 8000000 9016 OutputInfo ( "6596fd070679de96e405d52b51b8e1d644029108ec4cbfe451454486796a1ecf" , 0 ,
0000) 90 OutputInfo ( "b2affea89ff82557c60d635a2a3137b8f88f12ecec85082f7d0a1f82ee203ac4" , 0 , 10000) 10000) OutputInfo ( "7dbc497969c7475e45d952c4a872e213fb15d45e5cd3473c386a71a1b0c136a1" , 0 , OutputInfo ( "55ea01bd7e9afd3d3ab97e777d62a0709cf0725e80a7350fdb22d7b8ec6" , 17 , OutputInfo ( "12b6a7934c1df821945ee9ee3b3326d07ca7a65fd6416ea44ce8c3db0c078c64" , 0 , 10000) OutputInfo ( "7f42eda67921ee92eae5f79bd37c68c9cb859b899ce70dba68c48338857b7818" , 0 , 16100000 ] если длина ( argv ) > 1 : цель = длинный ( argv [ 1 ]) иначе : цель = 55000000 print «Для суммы транзакции % d Satoshis ( % f bitcoin) используйте:» % ( target , target /10.0 ** 8 ) печать select_outputs_greedy ( неизрасходовано , цель ) , если __name__ == "__main__" : main ()
Если мы запустим сценарий select-utxo.py без параметра, он попытается создать набор UTXO (и изменений) для выплаты 55000000 сатоши (0.55 биткойн). Если вы укажете целевую сумму платежа в качестве параметра, сценарий выберет UTXO для выполнения этой целевой суммы платежа. В примере 5-4 мы запускаем скрипт, пытаясь произвести платеж в размере 0,5 биткойна или 50 000 000 сатоши.
Пример 5-4. Запуск сценария select-utxo.py
$ python select-utxo.py 50000000 Для суммы транзакции 50000000 сатоши (0.500000 биткойнов) используйте: ([<7dbc497969c7475e45d952c4a872e213fb15d45e5cd3473c386a71a1b0c136a1: 0 с 25000000 Satoshis>, <7f42eda67921ee92eae5f79bd37c68c9cb859b899ce70dba68c48338857b7818: 0 с 16100000 Satoshis>, <6596fd070679de96e405d52b51b8e1d644029108ec4cbfe451454486796a1ecf: 0 с 16050000 Satoshis>], 'Изменение: 7150000 Satoshis')
После того, как UTXO выбран, бумажник затем производит разблокировку сценарии, содержащие сигнатуры для каждого UTXO, что делает их доступными для использования, удовлетворяя их условиям сценария блокировки.Кошелек добавляет эти ссылки UTXO и скрипты разблокировки в качестве входных данных для транзакции. Таблица 5-3 показывает структуру ввода транзакции.
Таблица 5-3. Структура ввода транзакции
быть потрачено
Размер Поле Описание
32 байта
Транзакция, содержащая хеш-код транзакции
4 байта
Индекс вывода
Номер индекса UTXO, который должен быть потрачен; первый - 0
1-9 байтов (VarInt)
Размер сценария разблокировки
Длина скрипта разблокировки в байтах, для последующего
Variable -Script
Сценарий, который выполняет условия сценария блокировки UTXO.
4 байта
Порядковый номер
В настоящее время отключена функция замены Tx, установлена на 0xFFFFFFFF
Примечание
Порядковый номер используется до отмены транзакции времени блокировки транзакции, которая в настоящее время отключена в биткойнах. Большинство транзакций устанавливают это значение на максимальное целочисленное значение (0xFFFFFFFF), и оно игнорируется сетью биткойнов.Если транзакция имеет ненулевое время блокировки, по крайней мере один из ее входов должен иметь порядковый номер ниже 0xFFFFFFFF, чтобы включить время блокировки.
Большинство транзакций включают комиссию за транзакцию, которая компенсирует майнерам биткойнов за обеспечение безопасности сети. Майнинг, а также сборы и вознаграждения, собираемые майнерами, более подробно обсуждаются в главе 8. В этом разделе рассматривается, как транзакционные комиссии включаются в типичную транзакцию. Большинство кошельков автоматически рассчитывают и включают комиссию за транзакцию.Однако, если вы создаете транзакции программно или с помощью интерфейса командной строки, вы должны вручную учитывать и включать эти комиссии.
Комиссионные за транзакции служат стимулом для включения (майнинга) транзакции в следующий блок, а также как сдерживающий фактор против «спамовых» транзакций или любого рода злоупотреблений в системе за счет небольших затрат на каждую транзакцию. Комиссию за транзакцию взимает майнер, который добывает блок, который записывает транзакцию в цепочке блоков.
Комиссия за транзакцию рассчитывается на основе размера транзакции в килобайтах, а не стоимости транзакции в биткойнах. В целом, комиссии за транзакции устанавливаются на основе рыночных сил в сети биткойнов. Майнеры определяют приоритет транзакций на основе множества различных критериев, включая комиссии, и могут даже обрабатывать транзакции бесплатно при определенных обстоятельствах. Комиссия за транзакцию влияет на приоритет обработки, а это означает, что транзакция с достаточной комиссией, вероятно, будет включена в следующий наиболее добываемый блок, в то время как транзакция с недостаточной комиссией или без комиссии может быть отложена и обработана с максимальной эффективностью после нескольких блоки или не обрабатываются совсем.Комиссия за транзакцию не является обязательной, и в конечном итоге транзакция без комиссии может быть обработана; тем не менее, включение комиссии за транзакцию способствует приоритетной обработке.
Со временем методы расчета комиссий за транзакции и их влияние на приоритизацию транзакций изменились. Сначала комиссии за транзакции были фиксированными и постоянными во всей сети. Постепенно структура комиссий была смягчена, чтобы на нее могли влиять рыночные силы в зависимости от пропускной способности сети и объема транзакций.Текущая минимальная комиссия за транзакцию установлена на уровне 0,0001 биткойна или десятой милли биткойна за килобайт, недавно снизившись с одного милли биткойна. Большинство транзакций составляют менее одного килобайта; однако те, у которых несколько входов или выходов, могут быть больше. Ожидается, что в будущих версиях протокола биткойнов приложения-кошельки будут использовать статистический анализ для расчета наиболее подходящей комиссии для присоединения к транзакции на основе средней комиссии за последние транзакции.
Текущий алгоритм, используемый майнерами для определения приоритетности транзакций для включения в блок на основе их комиссий, подробно рассматривается в главе 8.
Добавление комиссий к транзакциям
В структуре данных транзакций нет поля для комиссионных. Вместо этого, сборы подразумеваются как разница между суммой вложенных средств и суммой результатов. Любая избыточная сумма, которая остается после вычета всех выходов из всех входов, является комиссией, взимаемой майнерами.
Комиссия за транзакцию подразумевается как превышение входов минус выходы:
Сборы = Сумма (Входы) - Сумма (Выходы)
Это несколько сбивающий с толку элемент транзакций и важный момент, который необходимо понять, потому что, если вы создаете свои собственные транзакции, вы должны убедиться, что вы случайно не включили очень большую комиссию. из-за недостаточного расходования средств.Это означает, что вы должны учитывать все вводимые данные, если необходимо, путем внесения изменений, иначе вы в конечном итоге дадите майнерам очень большой совет!
Например, если вы потребляете UTXO на 20 биткойнов для совершения платежа в 1 биткойн, вы должны включить вывод сдачи 19 биткойнов обратно в свой кошелек. В противном случае «оставшиеся» 19 биткойнов будут считаться комиссией за транзакцию и будут собраны майнером, который майнит вашу транзакцию в блоке. Хотя вы получите приоритетную обработку и сделаете майнера очень счастливым, это, вероятно, не то, что вы планировали.
Предупреждение
Если вы забудете добавить выход изменения в транзакцию, созданную вручную, вы оплатите это изменение как комиссию за транзакцию. "Сдачи не надо!" может быть не тем, что вы хотели.
Давайте посмотрим, как это работает на практике, еще раз посмотрев на покупку кофе Алисой. Алиса хочет потратить 0,015 биткойна на оплату кофе. Чтобы обеспечить своевременную обработку этой транзакции, она захочет включить комиссию за транзакцию, скажем, 0,001. Это будет означать, что общая стоимость транзакции будет равна 0.016. Следовательно, ее кошелек должен быть источником набора UTXO, который в сумме составляет 0,016 биткойна или более, и, при необходимости, вносить изменения. Допустим, в ее кошельке есть UTXO на 0,2 биткойна. Следовательно, ему необходимо будет использовать этот UTXO, создать один выход для Bob’s Cafe за 0,015 и второй выход с 0,184 биткойна в обмен на свой собственный кошелек, оставив 0,001 биткойна нераспределенным в качестве неявной комиссии за транзакцию.
А теперь давайте посмотрим на другой сценарий. Евгения, директор благотворительной организации по работе с детьми на Филиппинах, завершила сбор средств на покупку школьных учебников для детей.Она получила несколько тысяч небольших пожертвований от людей со всего мира на общую сумму 50 биткойнов, поэтому ее кошелек заполнен очень маленькими платежами (UTXO). Теперь она хочет купить сотни школьных учебников у местного издателя, заплатив биткойнами.
Поскольку приложение кошелька Евгении пытается создать одну большую платежную транзакцию, оно должно исходить из доступного набора UTXO, который состоит из множества меньших сумм. Это означает, что результирующая транзакция будет исходить из более чем сотни мелких UTXO в качестве входных данных и только из одного выхода, оплачиваемого издателем книги.Транзакция с таким количеством входов будет больше одного килобайта, возможно, от 2 до 3 килобайт. В результате потребуется более высокая комиссия, чем минимальная сетевая плата в 0,0001 биткойн.
Приложение кошелька Евгении рассчитает соответствующую комиссию, измерив размер транзакции и умножив ее на комиссию за килобайт. Многие кошельки переплачивают комиссию за более крупные транзакции, чтобы обеспечить своевременную обработку транзакции. Более высокая комиссия объясняется не тем, что Евгения тратит больше денег, а тем, что ее транзакция более сложна и больше по размеру - комиссия не зависит от стоимости транзакции в биткойнах.
Объединение транзакций в цепочку и потерянные транзакции
Как мы видели, транзакции образуют цепочку, в которой одна транзакция расходует выходные данные предыдущей транзакции (известной как родительская) и создает выходные данные для последующей транзакции (известной как дочерняя) . Иногда целая цепочка транзакций, зависящих друг от друга, например, родительская, дочерняя и внучатая транзакции, создается одновременно для выполнения сложного транзакционного рабочего процесса, который требует, чтобы действительные дочерние элементы были подписаны до подписания родительской.Например, это метод, используемый в транзакциях CoinJoin, когда несколько сторон объединяют транзакции вместе, чтобы защитить свою конфиденциальность.
Когда по сети передается цепочка транзакций, они не всегда поступают в одном и том же порядке. Иногда ребенок может прийти раньше родителя. В этом случае узлы, которые сначала видят дочерний элемент, могут видеть, что он ссылается на родительскую транзакцию, которая еще не известна. Вместо того, чтобы отвергать дочерний элемент, они помещают его во временный пул, чтобы дождаться прибытия его родителя и распространить его на все остальные узлы.Пул транзакций без родителей известен как пул потерянных транзакций . После прибытия родителя любые сироты, которые ссылаются на UTXO, созданный родителем, освобождаются из пула, рекурсивно проходят повторную валидацию, а затем вся цепочка транзакций может быть включена в пул транзакций, готовая к майнингу в блоке. Цепочки транзакций могут быть сколь угодно длинными, с одновременной передачей любого количества поколений. Механизм удержания сирот в пуле сирот гарантирует, что в противном случае действительные транзакции не будут отклонены только потому, что их родительская транзакция была отложена, и что в конечном итоге цепочка, к которой они принадлежат, будет реконструирована в правильном порядке, независимо от порядка поступления.
Существует ограничение на количество потерянных транзакций, хранящихся в памяти, чтобы предотвратить атаку отказа в обслуживании против узлов биткойнов. Предел определен как MAX_ORPHAN_TRANSACTIONS в исходном коде эталонного клиента биткойнов. Если количество потерянных транзакций в пуле превышает MAX_ORPHAN_TRANSACTIONS , одна или несколько случайно выбранных потерянных транзакций исключаются из пула, пока размер пула не вернется в установленные пределы.
Сценарии транзакций и язык сценариев
Клиенты Биткойн проверяют транзакции, выполняя сценарий, написанный на языке сценариев, подобном Forth.И сценарий блокировки (обременение), помещенный в UTXO, и сценарий разблокировки, который обычно содержит подпись, написаны на этом языке сценариев. Когда транзакция подтверждена, сценарий разблокировки на каждом входе выполняется вместе с соответствующим сценарием блокировки, чтобы проверить, удовлетворяет ли он условию расходов.
Сегодня большинство транзакций, обрабатываемых через сеть биткойнов, имеют форму «Алиса платит Бобу» и основаны на том же сценарии, который называется сценарием Pay-to-Public-Key-Hash.Однако использование сценариев для блокировки выходов и разблокировки входов означает, что благодаря использованию языка программирования транзакции могут содержать бесконечное количество условий. Биткойн-транзакции не ограничиваются формой и шаблоном «Алиса платит Бобу».
Это только верхушка айсберга возможностей, которые могут быть выражены с помощью этого языка сценариев. В этом разделе мы продемонстрируем компоненты языка сценариев транзакций биткойнов и покажем, как его можно использовать для выражения сложных условий расходов и как эти условия могут быть выполнены с помощью сценариев разблокировки.
Подсказка
Проверка транзакции Биткойн не основана на статическом шаблоне, а выполняется с помощью языка сценариев. Этот язык позволяет выражать почти бесконечное множество условий. Так биткойн получает силу «программируемых денег».
Построение сценария (блокировка + разблокировка)
Механизм проверки транзакций Биткойн полагается на два типа сценариев для проверки транзакций: сценарий блокировки и сценарий разблокировки.
Сценарий блокировки - это обременение, налагаемое на вывод, и он определяет условия, которые должны быть выполнены для использования вывода в будущем. Исторически сценарий блокировки назывался scriptPubKey , потому что обычно он содержал открытый ключ или биткойн-адрес. В этой книге мы называем его «сценарием блокировки», чтобы признать гораздо более широкий диапазон возможностей этой технологии создания сценариев. В большинстве биткойн-приложений то, что мы называем сценарием блокировки, будет отображаться в исходном коде как scriptPubKey .
Сценарий разблокировки - это сценарий, который «решает» или удовлетворяет условиям, налагаемым на выход сценарием блокировки, и позволяет потратить выходные данные. Сценарии разблокировки являются частью каждой транзакции, и в большинстве случаев они содержат цифровую подпись, созданную кошельком пользователя с его или ее закрытого ключа. Исторически скрипт разблокировки называется scriptSig , потому что обычно он содержит цифровую подпись. В большинстве биткойн-приложений в исходном коде скрипт разблокировки называется scriptSig .В этой книге мы называем его «сценарием разблокировки», чтобы признать гораздо более широкий диапазон требований сценария блокировки, поскольку не все сценарии разблокировки должны содержать подписи.
Каждый биткойн-клиент будет проверять транзакции, выполняя сценарии блокировки и разблокировки вместе. Для каждого входа в транзакции программное обеспечение проверки сначала извлекает UTXO, на который ссылается вход. Этот UTXO содержит сценарий блокировки, определяющий условия, необходимые для его использования. Программное обеспечение проверки затем возьмет сценарий разблокировки, содержащийся во входных данных, который пытается потратить этот UTXO, и выполнит два сценария.
В исходном биткойн-клиенте скрипты разблокировки и блокировки были объединены и выполнялись последовательно. По соображениям безопасности это было изменено в 2010 году из-за уязвимости, которая позволяла некорректному сценарию разблокировки помещать данные в стек и повредить сценарий блокировки. В текущей реализации сценарии выполняются отдельно со стеком, передаваемым между двумя выполнениями, как описано ниже.
Сначала выполняется сценарий разблокировки с использованием механизма выполнения стека.Если сценарий разблокировки выполняется без ошибок (например, в нем не осталось «висящих» операторов), копируется основной стек (а не альтернативный стек) и выполняется сценарий блокировки. Если результатом выполнения сценария блокировки с данными стека, скопированными из сценария разблокировки, является «ИСТИНА», сценарий разблокировки преуспел в разрешении условий, налагаемых сценарием блокировки, и, следовательно, входные данные являются действительным разрешением на расходование UTXO. . Если после выполнения объединенного сценария остается какой-либо результат, отличный от «ИСТИНА», ввод недопустим, поскольку он не удовлетворяет условиям затрат, установленным для UTXO.Обратите внимание, что UTXO постоянно записывается в цепочку блоков и, следовательно, неизменен, и на него не влияют неудачные попытки потратить его по ссылке в новой транзакции. Только действительная транзакция, которая правильно удовлетворяет условиям UTXO, приводит к тому, что UTXO помечается как «потраченный» и удаляется из набора доступных (неизрасходованных) UTXO.
Рисунок 5-1 представляет собой пример сценариев разблокировки и блокировки для наиболее распространенного типа транзакции биткойнов (платеж на хэш открытого ключа), показывающий комбинированный сценарий, полученный в результате объединения сценариев разблокировки и блокировки перед сценарием. Проверка.
Рисунок 5-1. Комбинирование scriptSig и scriptPubKey для оценки сценария транзакции
Язык сценария транзакции биткойнов, называемый Script , является языком выполнения на основе стека обратной полировки нотации типа Форт. Если это звучит как тарабарщина, вы, вероятно, не изучали языки программирования 1960-х годов. Сценарий - это очень простой язык, который был разработан с учетом ограничений по объему и выполняемого на ряде аппаратных средств, возможно, таких же простых, как встроенное устройство, такое как карманный калькулятор.Он требует минимальной обработки и не может делать многие из фантастических вещей, которые могут делать современные языки программирования. В случае программируемых денег это преднамеренная функция безопасности.
Язык сценариев Биткойна называется языком на основе стека, потому что он использует структуру данных, называемую стеком . Стек - это очень простая структура данных, которую можно визуализировать как стопку карточек. Стек позволяет две операции: push и pop. Push добавляет элемент в верхнюю часть стека. Pop удаляет верхний элемент из стека.
Язык сценариев выполняет сценарий, обрабатывая каждый элемент слева направо. Числа (константы данных) помещаются в стек. Операторы выталкивают или выталкивают один или несколько параметров из стека, воздействуют на них и могут помещать результат в стек. Например, OP_ADD вытолкнет два элемента из стека, сложит их и поместит полученную сумму в стек.
Условные операторы оценивают условие, выдавая логический результат ИСТИНА или ЛОЖЬ. Например, OP_EQUAL выталкивает два элемента из стека и нажимает ИСТИНА (ИСТИНА представлено числом 1), если они равны, или ЛОЖЬ (представлено нулем), если они не равны.Скрипты биткойн-транзакций обычно содержат условный оператор, поэтому они могут выдавать ИСТИННЫЙ результат, обозначающий действительную транзакцию.
На рисунке 5-2 сценарий 2 3 OP_ADD 5 OP_EQUAL демонстрирует оператор арифметического сложения OP_ADD , складывающий два числа и помещающий результат в стек, за которым следует условный оператор OP_EQUAL , который проверяет, что Итоговая сумма равна 5 . Для краткости префикс OP_ в пошаговом примере опущен.
Ниже приведен немного более сложный сценарий, который вычисляет 2 + 7 - 3 + 1 . Обратите внимание, что когда сценарий содержит несколько операторов подряд, стек позволяет выполнять действия одного оператора следующему оператору:
2 7 OP_ADD 3 OP_SUB 1 OP_ADD 7 OP_EQUAL
Попробуйте проверить предыдущий сценарий самостоятельно, используя карандаш и бумага. Когда выполнение скрипта завершится, вы должны остаться со значением TRUE в стеке.
Хотя большинство сценариев блокировки ссылаются на адрес биткойна или открытый ключ, что требует подтверждения права собственности на использование средств, сценарий не должен быть таким сложным.Допустима любая комбинация сценариев блокировки и разблокировки, которая приводит к значению ИСТИНА. Простая арифметика, которую мы использовали в качестве примера языка сценариев, также является допустимым сценарием блокировки, который можно использовать для блокировки вывода транзакции.
Используйте часть сценария арифметического примера в качестве сценария блокировки:
3 OP_ADD 5 OP_EQUAL
, который может быть удовлетворен транзакцией, содержащей ввод со сценарием разблокировки:
2
Программное обеспечение проверки сочетает блокировку и разблокировку сценарии и результирующий сценарий:
2 3 OP_ADD 5 OP_EQUAL
Как мы видели в пошаговом примере на рисунке 5-2, когда этот сценарий выполняется, результатом является OP_TRUE , что делает транзакцию действительной. .Это не только действительный сценарий блокировки вывода транзакции, но и получившийся UTXO может быть использован любым, кто обладает арифметическими навыками, чтобы знать, что число 2 удовлетворяет сценарию.
Рисунок 5-2. Проверка сценария Биткойна с помощью простых вычислений
Совет
Транзакции действительны, если верхний результат в стеке ИСТИНА (обозначен как {0x01} ), любое другое ненулевое значение или если стек пуст после выполнения сценария. Транзакции недействительны, если верхнее значение в стеке равно FALSE (пустое значение нулевой длины, обозначенное как {} ) или если выполнение скрипта явно остановлено оператором, таким как OP_VERIFY, OP_RETURN, или условным ограничителем, например OP_ENDIF.См. Подробности в Приложении A.
Язык сценария транзакции биткойнов содержит множество операторов, но намеренно ограничен одним важным способом - нет никаких циклов или сложных возможностей управления потоком, кроме условного управления потоком. Это гарантирует, что язык не Turing Complete , а это означает, что скрипты имеют ограниченную сложность и предсказуемое время выполнения. Скрипт не является языком общего назначения. Эти ограничения гарантируют, что язык не может быть использован для создания бесконечного цикла или другой формы «логической бомбы», которая может быть встроена в транзакцию таким образом, чтобы вызвать атаку отказа в обслуживании против сети биткойнов.Помните, что каждая транзакция проверяется каждым полным узлом сети биткойнов. Ограниченный язык предотвращает использование механизма проверки транзакции в качестве уязвимости.
Язык сценария транзакции биткойнов не имеет состояния, т.е. нет состояния до выполнения сценария или состояния, сохраненного после выполнения сценария. Следовательно, вся информация, необходимая для выполнения сценария, содержится внутри сценария. Сценарий предсказуемо будет выполняться одинаково в любой системе.Если ваша система проверяет сценарий, вы можете быть уверены, что каждая другая система в сети биткойнов также проверит сценарий, а это означает, что действительная транзакция действительна для всех, и все это знают. Эта предсказуемость результатов - важное преимущество системы биткойнов.
В первые несколько лет разработки биткойна разработчики ввели некоторые ограничения в типы скриптов, которые могут обрабатываться эталонным клиентом. Эти ограничения закодированы в функции isStandard () , которая определяет пять типов «стандартных» транзакций.Эти ограничения являются временными и могут быть сняты к тому времени, когда вы прочитаете это. До тех пор пять стандартных типов скриптов транзакций - единственные, которые будут приняты эталонным клиентом и большинством майнеров, запускающих эталонный клиент. Хотя можно создать нестандартную транзакцию, содержащую сценарий, который не является одним из стандартных типов, вы должны найти майнера, который не соблюдает эти ограничения, чтобы превратить эту транзакцию в блок.
Проверьте исходный код клиента Bitcoin Core (эталонная реализация), чтобы узнать, что в настоящее время разрешено в качестве допустимого сценария транзакции.
Пять стандартных типов сценариев транзакций: хэш-код с оплатой по общему ключу (P2PKH), с открытым ключом, с мультиподписью (до 15 ключей), хеш с оплатой по сценарию (P2SH) и с данными. output (OP_RETURN), которые более подробно описаны в следующих разделах.
Pay-to-Public-Key-Hash (P2PKH)
Подавляющее большинство транзакций, обрабатываемых в сети биткойнов, являются транзакциями P2PKH. Они содержат сценарий блокировки, который обременяет вывод хешем открытого ключа, более известным как адрес биткойна.Транзакции, которые оплачивают биткойн-адрес, содержат скрипты P2PKH. Вывод, заблокированный сценарием P2PKH, можно разблокировать (потратить), представив открытый ключ и цифровую подпись, созданную соответствующим закрытым ключом.
Например, давайте еще раз посмотрим на платеж Алисы в адрес Bob’s Cafe. Алиса перевела 0,015 биткойна на биткойн-адрес кафе. Этот вывод транзакции будет иметь сценарий блокировки вида:
OP_DUP OP_HASh260 <Хэш открытого ключа кафе> OP_EQUAL OP_CHECKSIG
Хэш открытого ключа кафе эквивалентен биткойн-адресу кафе без кодировки Base58Check.Большинство приложений будут отображать хэш открытого ключа в шестнадцатеричной кодировке, а не знакомый формат адреса биткойнов Base58Check, который начинается с «1».
Предыдущий сценарий блокировки может быть удовлетворен сценарием разблокировки в форме:
<Подпись кафе> <Открытый ключ кафе>
Два сценария вместе образуют следующий комбинированный сценарий проверки:
<Подпись кафе> <Кафе Открытый ключ> OP_DUP OP_HASh260 <Хэш открытого ключа Cafe> OP_EQUAL OP_CHECKSIG
При выполнении этот комбинированный сценарий будет оцениваться как TRUE, если и только если сценарий разблокировки соответствует условиям, установленным сценарием блокировки.Другими словами, результатом будет ИСТИНА, если сценарий разблокировки имеет действительную подпись из закрытого ключа кафе, которая соответствует хешу открытого ключа, установленному в качестве обременения.
На рисунках 5-3 и 5-4 показано (в двух частях) пошаговое выполнение комбинированного сценария, который докажет, что это действительная транзакция.
Рисунок 5-3. Оценка скрипта для транзакции P2PKH (Часть 1 из 2)
Pay-to-public-key - более простая форма биткойн-платежа, чем pay-to-public-key-hash.В этой форме сценария сам открытый ключ хранится в сценарии блокировки, а не в хэше открытого ключа, как раньше в P2PKH, который намного короче. Pay-to-public-key-hash был изобретен Сатоши, чтобы сделать биткойн-адреса короче для простоты использования. Плата за открытый ключ теперь чаще всего встречается в транзакциях с базой монет, генерируемых старым программным обеспечением для майнинга, которое не было обновлено для использования P2PKH.
Сценарий блокировки с оплатой по общему ключу выглядит следующим образом:
<Открытый ключ A> OP_CHECKSIG
Соответствующий сценарий разблокировки, который должен быть представлен, чтобы разблокировать этот тип выходных данных, представляет собой простую подпись, например:
<Подпись из закрытого ключа A>
Комбинированный сценарий, который проверяется программным обеспечением для проверки транзакций, имеет следующий вид:
<Подпись из закрытого ключа A> <Открытый ключ A> OP_CHECKSIG
Этот сценарий представляет собой простой вызов Оператор CHECKSIG , который проверяет подпись как принадлежащую правильному ключу и возвращает TRUE в стеке.
Рисунок 5-4. Оценка сценария для транзакции P2PKH (Часть 2 из 2)
Сценарии с несколькими подписями устанавливают условие, при котором N открытых ключей записываются в сценарий, и по крайней мере M из них должны предоставлять подписи для освобождения от обременения. Это также известно как схема M-of-N, где N - общее количество ключей, а M - порог подписей, необходимых для проверки. Например, мульти-подпись 2-из-3 - это та, в которой три открытых ключа указаны в качестве потенциальных подписывающих лиц, и по крайней мере два из них должны использоваться для создания подписей для действительной транзакции для расходования средств.В настоящее время стандартные сценарии с несколькими подписями ограничены максимум 15 перечисленными открытыми ключами, что означает, что вы можете делать что угодно, от 1-из-1 до мульти-подписи 15-из-15 или любую комбинацию в этом диапазоне. Ограничение до 15 перечисленных ключей может быть снято к моменту публикации этой книги, поэтому проверьте функцию isStandard () , чтобы узнать, что в настоящее время принимается сетью.
Общая форма сценария блокировки, устанавливающего условие множественной подписи M-of-N:
M <Открытый ключ 1> <Открытый ключ 2>... <Открытый ключ N> N OP_CHECKMULTISIG
где N - общее количество перечисленных открытых ключей, а M - порог необходимых подписей для использования вывода.
Сценарий блокировки, устанавливающий условие мультиподписи 2 из 3, выглядит следующим образом:
2 <Открытый ключ A> <Открытый ключ B> <Открытый ключ C> 3 OP_CHECKMULTISIG
Предыдущий сценарий блокировки может быть удовлетворен с помощью сценарий разблокировки, содержащий пары подписей и открытых ключей:
OP_0 <Подпись B> <Подпись C>
или любую комбинацию двух подписей из закрытых ключей, соответствующих трем перечисленным открытым ключам.
Примечание
Префикс OP_0 требуется из-за ошибки в исходной реализации CHECKMULTISIG , когда из стека выскакивает слишком много элементов. Он игнорируется CHECKMULTISIG и является просто заполнителем.
Два сценария вместе образуют объединенный сценарий проверки:
OP_0 <Подпись B> <Подпись C> 2 <Открытый ключ A> <Открытый ключ B> <Открытый ключ C> 3 OP_CHECKMULTISIG
При выполнении этот объединенный сценарий будет оцениваться как ИСТИНА, если и только если скрипт разблокировки соответствует условиям, установленным скриптом блокировки.В этом случае условием является наличие у сценария разблокировки действительной подписи из двух закрытых ключей, которые соответствуют двум из трех открытых ключей, установленных в качестве обременения.
Распределенная бухгалтерская книга Биткойна с отметками времени, блокчейн, имеет потенциальное применение далеко за пределами платежей. Многие разработчики пытались использовать язык сценариев транзакций, чтобы воспользоваться преимуществами безопасности и отказоустойчивости системы для таких приложений, как цифровые нотариальные услуги, сертификаты акций и смарт-контракты.Ранние попытки использовать язык сценариев биткойна для этих целей включали создание выходных данных транзакций, которые записывали данные в цепочку блоков; например, чтобы записать цифровой отпечаток файла таким образом, чтобы любой мог установить доказательство существования этого файла на определенную дату, ссылаясь на эту транзакцию.
Использование цепочки блоков биткойнов для хранения данных, не связанных с платежами в биткойнах, является спорной темой. Многие разработчики считают такое использование оскорбительным и не одобряют его.Другие рассматривают это как демонстрацию мощных возможностей технологии блокчейн и хотят поощрять такие эксперименты. Те, кто возражает против включения данных о неплатежах, утверждают, что это вызывает «раздувание блокчейна», обременяя тех, кто использует полные биткойн-узлы, несут расходы на дисковое хранилище для данных, которые блокчейн не предназначен для передачи. Более того, такие транзакции создают UTXO, которые нельзя потратить, используя биткойн-адрес назначения как 20-байтовое поле произвольной формы. Поскольку адрес используется для данных, он не соответствует закрытому ключу, и полученный UTXO не может быть потрачен никогда; это поддельный платеж.Эта практика приводит к увеличению размера установленного в памяти UTXO, и, следовательно, эти транзакции, которые никогда не могут быть потрачены, никогда не удаляются, вынуждая узлы биткойнов нести их навсегда в ОЗУ, что намного дороже.
В версии 0.9 клиента Bitcoin Core компромисс был достигнут с введением оператора OP_RETURN . OP_RETURN позволяет разработчикам добавлять 40 байтов данных о неплатежах к выходным данным транзакции. Однако, в отличие от использования «фальшивого» UTXO, оператор OP_RETURN создает явно непригодный вывод , который не нужно сохранять в наборе UTXO. OP_RETURN Выходные данные записываются в блокчейн, поэтому они занимают дисковое пространство и способствуют увеличению размера блокчейна, но они не хранятся в наборе UTXO и, следовательно, не раздувают пул памяти UTXO и не обременяют полные узлы затратами. более дорогой оперативной памяти.
Сценарии OP_RETURN выглядят следующим образом:
OP_RETURN <данные>
Часть данных ограничена 40 байтами и чаще всего представляет собой хэш, например результат алгоритма SHA256 (32 байта).Многие приложения ставят перед данными префикс, чтобы помочь идентифицировать приложение. Например, в службе цифрового нотариального удостоверения «Доказательство существования» используется 8-байтовый префикс «DOCPROOF», который имеет кодировку ASCII как 44f4350524f4f46 в шестнадцатеричном формате.
Имейте в виду, что не существует «сценария разблокировки», соответствующего OP_RETURN , который мог бы быть использован для «расходования» вывода OP_RETURN . Весь смысл OP_RETURN заключается в том, что вы не можете потратить деньги, заблокированные в этом выпуске, и, следовательно, их не нужно хранить в UTXO как потенциально пригодные для использования - OP_RETURN - это , которые доказуемо нельзя потратить . OP_RETURN обычно является выходом с нулевым количеством биткойнов, потому что любой биткойн, назначенный такому выходу, фактически теряется навсегда. Если программа проверки подлинности сценария обнаруживает ошибку OP_RETURN , это немедленно приводит к остановке выполнения сценария проверки и пометке транзакции как недействительной. Таким образом, если вы случайно ссылаетесь на выход OP_RETURN как на вход транзакции, эта транзакция недействительна.
Стандартная транзакция (та, которая соответствует проверкам isStandard () ) может иметь только один выход OP_RETURN .Однако один выход OP_RETURN может быть объединен в транзакции с выходами любого другого типа.
Pay-to-Script-Hash (P2SH)
Pay-to-script-hash (P2SH) был представлен в 2012 году как мощный новый тип транзакции, который значительно упрощает использование сложных сценариев транзакций. Чтобы объяснить необходимость P2SH, давайте рассмотрим практический пример.
В главе 1 мы представили Мохаммеда, импортера электроники из Дубая. Компания Мохаммеда широко использует функцию мультиподписи биткойнов для своих корпоративных счетов.Сценарии с несколькими подписями - одно из наиболее распространенных применений расширенных возможностей сценариев Биткойна и очень мощная функция. Компания Мохаммеда использует сценарий с несколькими подписями для всех платежей клиентов, известный в бухгалтерском учете как «дебиторская задолженность» или AR. При использовании схемы с несколькими подписями любые платежи, производимые клиентами, блокируются таким образом, что для их выпуска требуется как минимум две подписи, от Мохаммеда и одного из его партнеров или от его поверенного, у которого есть резервный ключ. Подобная схема с несколькими подписями обеспечивает контроль корпоративного управления и защищает от краж, растраты или потери.
Результирующий сценарий довольно длинный и выглядит следующим образом:
2 <Открытый ключ Мохаммеда> <Открытый ключ партнера1> <Открытый ключ партнера2> <Открытый ключ партнера3> <Открытый ключ поверенного> 5 OP_CHECKMULTISIG
Хотя сценарии с несколькими подписями являются мощной функцией, они громоздки в использовании. Учитывая предыдущий сценарий, Мохаммед должен был бы передать этот сценарий каждому покупателю до оплаты. Каждый клиент должен будет использовать специальное программное обеспечение для биткойн-кошелька с возможностью создания пользовательских сценариев транзакций, и каждый клиент должен будет понимать, как создать транзакцию с использованием пользовательских сценариев.Более того, итоговая транзакция будет примерно в пять раз больше, чем простая платежная транзакция, потому что этот сценарий содержит очень длинные открытые ключи. Бремя этой сверхкрупной транзакции ляжет на плечи клиента в виде комиссионных. Наконец, такой большой скрипт транзакции будет переноситься в UTXO, установленном в ОЗУ на каждом полном узле, до тех пор, пока он не будет израсходован. Все эти проблемы затрудняют использование сложных сценариев вывода на практике.
Pay-to-script-hash (P2SH) был разработан для решения этих практических трудностей и для упрощения использования сложных скриптов, таких как оплата на биткойн-адрес.В платежах P2SH сложный скрипт блокировки заменяется его цифровым отпечатком - криптографическим хешем. Когда транзакция, пытающаяся потратить UTXO, представляется позже, она должна содержать сценарий, соответствующий хэшу, в дополнение к сценарию разблокировки. Проще говоря, P2SH означает «заплатить скрипту, соответствующему этому хешу, скрипту, который будет представлен позже, когда эти выходные данные будут потрачены».
В транзакциях P2SH сценарий блокировки, который заменяется хешем, называется сценарием погашения , потому что он представляется системе во время погашения, а не как сценарий блокировки.В таблице 5-4 показан сценарий без P2SH, а в таблице 5-5 показан тот же сценарий, закодированный с помощью P2SH.
Таблица 5-4. Сложный скрипт без P2SH
Сценарий блокировки
2 PubKey1 PubKey2 PubKey3 PubKey4 PubKey5 5 OP_CHECKMULTISIG
9295 9034
9295 9034 -5. Сложный скрипт как P2SH
9302 9306
9302
Скрипт OP_CHECKMULTISIG OP_EQUAL
Скрипт Redeem> Скрипт Redeem
2 PubKey1 PubKey2 PubKey3 PubKey4 PubKey5 5 OP_CHECKMULTISIG
Сценарий разблокировки
Sig1 Сценарий погашения Sig2
Как видно из таблиц, с P2SH сложный скрипт, который детализирует условия расходования выходных данных (не скрипт погашения) представлен в сценарии блокировки.Вместо этого в скрипте блокировки содержится только его хэш, а сам скрипт погашения будет представлен позже как часть скрипта разблокировки, когда выходные данные будут потрачены. Это перекладывает бремя комиссий и сложности с отправителя на получателя (спонсора) транзакции.
Давайте посмотрим на компанию Мохаммеда, сложный сценарий с несколькими подписями и полученные сценарии P2SH.
Во-первых, сценарий с несколькими подписями, который компания Мохаммеда использует для всех входящих платежей от клиентов:
2 <Открытый ключ Мохаммеда> <Открытый ключ партнера1> <Открытый ключ партнера2> <Открытый ключ партнера3> <Открытый ключ поверенного> 5 OP_CHECKMULTISIG
Если заполнители заменены фактическими открытыми ключами (показаны здесь как 520-битные числа, начинающиеся с 04), вы увидите, что этот сценарий становится очень длинным:
2 04C16B8698A9ABF84250A7C3EA7EEDEF9897D1C8C6ADF47F06CF73370D74DCCA01CDCA79DCC5C395D7EEC6984D83F1F50C900A24DD47F569FD4193AF5DE762C58704A2192968D8655D6A935BEAF2CA23E3FB87A3495E7AF308EDF08DAC3C1FCBFC2C75B4B0F4D0B1B70CD2423657738C0C2B1D5CE65C97D78D0E34224858008E8B49047E63248B75DB7379BE9CDA8CE5751D16485F431E46117B9D0C1837C9D5737812F393DA7D4420D7E1A9162F0279CFC10F1E8E8F3020DECDBC3C0DD389D99779650421D65CBD7149B255382ED7F78E946580657EE6FDA162A187543A9D85BAAA93A4AB3A8F044DADA618D087227440645ABE8A35DA8C5B73997AD343BE5C2AFD94A5043752580AFA1ECED3C68D446BCAB69AC0BA7DF50D56231BE0AABF1FDEEC78A6A45E394BA29A1EDF518C022DD618DA774D207D137AAB59E0B000EB7ED238F4D800 5 OP_CHECKMULTISIG
Этот сценарий может вместо этого быть представлена 20-байтовой криптографический хэш, сначала путем применения алгоритма хэширования SHA256, а затем применения алгоритма ripemd160 на результат.20-байтовый хэш предыдущего сценария:
54c557e07dde5bb6cb791c7a540e0a4796f5e97e
Транзакция P2SH блокирует вывод в этот хэш вместо более длинного сценария, используя сценарий блокировки:
OP_HAS716h2605 намного короче. Вместо того, чтобы «заплатить этому скрипту с несколькими подписями с 5 ключами», эквивалентная транзакция P2SH - «заплатить скрипту с этим хешем». Клиенту, производящему платеж компании Мохаммеда, нужно только включить этот гораздо более короткий скрипт блокировки в свой платеж.Когда Мохаммед хочет потратить этот UTXO, он должен представить исходный скрипт погашения (тот, чей хэш заблокировал UTXO) и подписи, необходимые для его разблокировки, например:

<2 PK1 PK2 PK3 PK4 PK5 5 OP_CHECKMULTISIG>
Два сценария объединяются в два этапа. Сначала скрипт погашения сравнивается со скриптом блокировки, чтобы убедиться, что хеш-код совпадает:
<2 PK1 PK2 PK3 PK4 PK5 5 OP_CHECKMULTISIG> OP_HASh260 OP_EQUAL
Если хэш скрипта погашения совпадает, сценарий разблокировки выполняется самостоятельно, чтобы разблокировать скрипт погашения:
2 PK1 PK2 PK3 PK4 PK5 5 OP_CHECKMULTISIG
Pay-to-script-hash Address
Другой важной частью функции P2SH является возможность для кодирования хэша сценария как адреса, как определено в BIP0013.Адреса P2SH представляют собой кодировки Base58Check 20-байтового хэша сценария, точно так же, как адреса биткойнов представляют собой кодировки Base58Check 20-байтового хеша открытого ключа. Адреса P2SH используют префикс версии «5», в результате чего адреса в кодировке Base58Check начинаются с «3». Например, сложный сценарий Мохаммеда, хешированный и закодированный с помощью Base58Check как адрес P2SH, становится 39RF6JqABiHdYHkfChV6USGMe6Nsr66Gzw . Теперь Мохаммед может дать этот «адрес» своим клиентам, и они могут использовать практически любой биткойн-кошелек для простой оплаты, как если бы это был биткойн-адрес.Префикс 3 подсказывает им, что это особый тип адреса, соответствующий сценарию, а не публичному ключу, но в остальном он работает точно так же, как платеж на адрес биткойна.
P2SH-адресов скрывают всю сложность, так что человек, производящий платеж, не видит скрипт.
Преимущества хеширования pay-to-script
Функция pay-to-script-hash предлагает следующие преимущества по сравнению с прямым использованием сложных сценариев для блокировки выходов:
Сложные сценарии заменяются более короткими отпечатками пальцев в выводе транзакции, что делает транзакцию меньше.
Сценарии могут быть закодированы как адрес, поэтому отправителю и кошельку отправителя не требуется сложная инженерия для реализации P2SH.
P2SH перекладывает бремя создания сценария на получателя, а не на отправителя.
P2SH переносит бремя хранения данных для длинного скрипта с вывода (который находится в наборе UTXO и, следовательно, влияет на память) на ввод (хранящийся только в блокчейне).
P2SH переносит нагрузку по хранению данных для длинного скрипта с настоящего времени (платеж) на время в будущем (когда оно будет потрачено).
P2SH перекладывает стоимость транзакционной комиссии за длинный скрипт с отправителя на получателя, который должен включить длинный скрипт погашения, чтобы потратить его.
Сценарий погашения и проверка isStandard
До версии 0.9.2 клиента Bitcoin Core хеширование pay-to-script было ограничено стандартными типами сценариев транзакций биткойнов функцией isStandard () . Это означает, что сценарий погашения, представленный в транзакции расходования, может быть только одного из стандартных типов: P2PK, P2PKH или с несколькими подписями, за исключением OP_RETURN и самого P2SH.
Начиная с версии 0.9.2 клиента Bitcoin Core, транзакции P2SH могут содержать любой допустимый сценарий, что делает стандарт P2SH гораздо более гибким и позволяет экспериментировать со многими новыми и сложными типами транзакций.
Обратите внимание, что вы не можете поместить P2SH в сценарий погашения P2SH, потому что спецификация P2SH не является рекурсивной. Вы также по-прежнему не можете использовать OP_RETURN в сценарии погашения, поскольку OP_RETURN не может быть погашен по определению.
Обратите внимание, что, поскольку сценарий погашения не представлен в сети, пока вы не попытаетесь потратить вывод P2SH, если вы заблокируете вывод с помощью хэша недействительной транзакции, он будет обработан независимо. Однако вы не сможете их потратить, потому что транзакция расходования, которая включает сценарий погашения, не будет принята, поскольку это недопустимый сценарий. Это создает риск, потому что вы можете заблокировать биткойн в P2SH, который нельзя будет потратить позже. Сеть примет обременение P2SH, даже если оно соответствует недопустимому сценарию погашения, поскольку хэш сценария не указывает на сценарий, который он представляет.
Предупреждение
Сценарии блокировки P2SH содержат хэш сценария погашения, который не дает никаких подсказок относительно содержимого самого скрипта погашения. Транзакция P2SH будет считаться действительной и принята, даже если сценарий погашения недействителен. Вы можете случайно заблокировать биткойн таким образом, чтобы его нельзя было потратить позже.
Компания Point72 Ventures из Стэмфорда возглавляет раунд финансирования на 35 миллионов долларов в чикагской финтех-фирме
STAMFORD - Point72 Ventures, венчурная компания, основанная миллиардером, инвестором хедж-фонда Стивеном Коэном, объявила, что она возглавляет раунд финансирования серии C на 35 миллионов долларов в финансовой сфере. -технология фирмы Zero Hash.
«Zero Hash разработала уникальную платформу, которая помогает финтех-компаниям и финансовым учреждениям гибко и согласованно встраивать криптовалютные продукты и возможности в свои приложения», - говорится в заявлении партнера Point72 Ventures Адама Карсона. «Мы считаем, что встроенные финансовые решения, такие как платформа криптографического API Zero Hash, помогут сыграть важную роль в обеспечении более широкого внедрения цифровых активов, позволяя потребителям получать доступ к криптовалюте через финтех-приложения и бренды финансовых услуг, которые они уже используют и которым доверяют.”
Новое финансирование, которое также включает взносы ряда других инвесторов, поможет Zero Hash из Чикаго продолжать расширять ассортимент своих продуктов, которые распространяются на рынки децентрализованного финансирования (DeFi) и невзаимозаменяемых токенов (NFT), согласно должностным лицам компании.
Эти средства также помогут компании расширить свою команду за счет подразделений комплаенс, маркетинга, продуктов и инженерии. Компания почти удвоила количество сотрудников с начала 2021 года и недавно достигла прибыльности.
Кроме того, компания заявила, что планирует расширить свою глобальную систему лицензирования и совершить приобретения.
Zero Hash сообщил, что он поддерживает некоторые из крупнейших «необанков», включая MoneyLion и Wirex, а также брокеров-дилеров, включая deliciousworks и TradeStation. Zero Hash также заявила, что работает с «некоторыми из крупнейших брендов в экосистеме финансовых технологий и финансовых услуг» для предоставления предстоящих предложений криптовалюты.
«Zero Hash определяет совершенно новую финтех-вертикаль« цифровые активы как услуга », - говорится в заявлении Эдварда Вудфорда, основателя и генерального директора компании.«Zero Hash - это платформа встроенной инфраструктуры B2B, которая позволяет любой платформе быстро и легко интегрировать цифровые активы в собственный опыт работы с клиентами».
Среди других транзакций в 2021 году Point72 Ventures объявила в феврале, что она возглавляет инвестицию в размере 90 миллионов долларов в Shield AI, компанию по разработке программного обеспечения для беспилотных автомобилей. В январе компания сообщила, что инвестировала почти 19 миллионов долларов в финансово-технологическую фирму Trade Ledger.Также в январе Ventures заявила, что участвует в инвестировании 7 миллионов долларов в Swapp, фирму, занимающуюся проектированием строительных технологий.
Ventures была основана в мае 2016 года, примерно через два с половиной года после того, как житель Гринвича Коэн основал основную инвестиционную фирму, которой он руководит сегодня, хедж-фонд Point72 из Стэмфорда. Запуск Ventures стал ответом на большой объем сделок, заключенных с Коэном.
Всего Ventures инвестировала более чем в 70 компаний.У Ventures есть офисы в штаб-квартире Point72 по адресу 72 Cummings Point Road в районе Стэмфорд Уотерсайд, а также в других городах Нью-Йорка и Пало-Альто, Калифорния. Она работает отдельно от хедж-фонда, но своими идеями делится с последним.
[email protected]; twitter: @paulschott

Обзор
О нулевом хешировании
Zero Hash - это служебная программа для институциональных расчетов в области цифровых активов.Предлагая набор пост-торговых расчетных услуг институционального уровня, Zero Hash является ведущим мультиплатформенным и мультикастодиальным расчетным агентом, который может облегчить расчет торговых обязательств и доставку активов для постоянно растущего списка торгуемых продуктов, включая спот, деривативы и займы.
Zero Hash - это зарегистрированная в FinCEN компания по оказанию денежных услуг, а также служба денежных переводов в более чем 45 штатах. Zero Hash имеет лицензию на виртуальную валюту от NYDFS и регистрацию в качестве компании по оказанию денежных услуг в FinCEN (США) и FINTRAC (Канада).В июне Zero Hash был признан новатором года по версии журнала Profit & Loss Readers Choice Awards 2019. Это последовало за успешным запуском дочерней компанией набора услуг по расчетам по внебиржевой торговле цифровыми активами в начале этого года.
Дополнительную информацию можно найти здесь.
Цель документации
Цель состоит в том, чтобы предоставить новому клиенту, платформе или хранителю четкий путь к интеграции с экосистемой Zero Hash. Одним из основных принципов Zero Hash является `` максимальная гибкость '', поэтому этот документ не только предоставит вам полный набор доступных конечных точек API и параметров подключения, но также предложит реализации, которые помогут вам подумать о том, какие параметры наиболее применимы к ваш вариант использования.
Как правило, сделки могут быть отправлены либо через наш REST API, либо через наш шлюз FIX Straight Through Processing (STP).
Пожалуйста, направляйте свои вопросы по электронной почте на адрес [адрес электронной почты защищен].
Или обратитесь в нашу службу поддержки по телефону (312) 858-6300.
Справочный центр с часто задаваемыми вопросами находится здесь.
Среды
Zero Hash предоставляет две различные среды: производственную и сертификационную.
Производство
Производственная среда существует для работы с действующей платформой, отправки сделок, управления депозитами и снятием средств, а также управления клиентами на вашей платформе.Рекомендуется, чтобы приложения провели пробные запуски в среде сертификации перед тем, как совершать сделки в реальном времени и использовать данные реального рынка.
Часы
Zero Hash работает круглосуточно и без выходных.
Связь с производством
Сертификация
Zero Hash имеет Среду сертификации, которая предлагает полную функциональность расчетов с использованием тестовых фондов. Все средства предназначены только для тестирования.
Среда сертификации доступна для приложений, чтобы подтвердить и подтвердить свою готовность к работе с системами Zero Hash.
Post navigation
Previous post
Ласкать женщин: D1 87 d0 b5 d0 bb d0 be d0 b2 d0 b5 d0 ba d0 bb d0 b0 d1 81 d0 ba d0 b0 d1 82 d1 8c d0 b6 d0 b5 d0 bd d1 89 d0 b8 d0 bd d1 83 картинки, стоковые фото D1 87 d0 b5 d0 bb d0 be d0 b2 d0 b5 d0 ba d0 bb d0 b0 d1 81 d0 ba d0 b0 d1 82 d1 8c d0 b6 d0 b5 d0 bd d1 89 d0 b8 d0 bd d1 83
Next post
Не привлекаю девушек: Страница не найдена — Мужской журнал MENSBY.COM
Добавить комментарий Отменить ответ
Ваш адрес email не будет опубликован. Обязательные поля помечены *
Комментарий *
Имя *
Email *
Сайт

Рубрики
Измена
Как вернуть отношения
Муж
Отношения
Советы
Разное
© 2024 ООО "Электрон НВ"

Путь HD	Описанный ключ
m / 0	Первый (0) дочерний закрытый ключ из главного ключа (m)
m / 0/0	Первый закрытый ключ внука первого ребенка (m / 0)
m / 0 ‘/ 0	Первый нормальный внук первый закаленный дочерний (м / 0 ‘)
м / 1/0	Первый закрытый ключ внука второго ребенка (м / 1)
M / 23 / 17/0/0	Первый праправнук открытый ключ первого правнука 18-го внука 24-го ребенка

Путь HD	Описание ключа
M / 44 ‘/ 0’ / 0 ‘/ 0/2	Третий принимающий открытый ключ для основного счета биткойнов
M / 44 ‘/ 0’ / 3 ‘/ 1/14	Пятнадцатый открытый ключ смены адреса для четвертого счета биткойнов
м / 44 ‘/ 2’ / 0 ‘/ 0/1	Второй закрытый ключ в основной учетной записи Litecoin для подписи транзакций

Размер	Поле	Описание
4 байта	Транзакция
	1–9 байт (VarInt)	Счетчик входов	Сколько входов включено
Переменная	Входы	02 06	02 Один или несколько входов 1–9 байтов (VarInt)	Счетчик выходов	Сколько выходов включено
Переменная	Выходы			Lockt ime	Временная метка Unix или номер блока