Community

@technol0g said in Обновление Node-A v.0.1.3:

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

Проведен рефакторинг sthjs-wrapper

соотвественно обновлены

https://api.smartholdem.io/#js-api-wrapper-0-1-6 https://github.com/smartholdem/faucet

модуль также доступен в npm https://www.npmjs.com/package/sthjs-wrapper

установка npm install --save sthjs-wrapper инициализация перед использованием // init var smartholdemApi = require("sthjs-wrapper"); var network = "main" //or "dev" smartholdemApi.init(network); использование var smartholdemApi = require("sthjs-wrapper") smartholdemApi.getBalance("Address of the account", (error, success, response) => { console.log(response); });

Trusted Execution Environment SmartHoldem (TEESH) набор программных компонентов, поддерживающих на устройстве безопасную среду выполнения операций экосистемы SmartHoldem.

Состоит из:

Операционной системы (SH Trusty ОС), работающей на процессоре, поддерживающем TEE Драйверов для ядра Linux, обеспечивающих взаимодействие с приложениями, работающими под SH Trusty OS Набора библиотек для взаимодействия с доверенными приложениями, выполняемыми внутри SH Trusty OS, использующего драйверы ядра API для взаимодействия с распределенными узлами SmartHoldem из внешнего небезопасного мира

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

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

Самый популярный пример всего этого в экосистеме Android — это DRM framework, используемый для защиты контента. ПО, работающее в Trusted Execution Environment процессоре, может получать доступ к специфичным для этого устройства ключам, которые нужны для расшифровки защищённого контента. При хорошо организованной защите от программных атак, основной процессор видит только зашифрованный контент.

Другие примеры использования Trusted Execution Environment: полнодисковое шифрование, многофакторная аутентификация, защита от сброса устройства, защита карт памяти, беспроводная трансляция защищённого контента, безопасная обработка PIN кодов и отпечатков пальцев.

Trusty предоставляет API для разработчиков двух классов приложений:

Доверенные приложения или сервисы, работающие на TEE процессоре Обычные/не доверенные приложения, которые работают на основном процессоре и используют сервисы, предоставляемые доверенными приложениями

ПО, работающее на основном процессоре, может использовать Trusty API для подключения к доверенным приложениям и обмениваться с ними различными сообщениями, подобно тому, как работают сетевые сервисы через IP. Используя определённый протокол, приложения определяют формат данных и семантики этих сообщений. Надёжность доставки этих сообщений гарантируется инфраструктурой, лежащей в основе Trusty (в виде драйверов, работающих на основном процессоре). Все сообщения асинхронны.

Доверенные сервисы

Доверенные приложения работают как изолированные процессы под ядром ОС Trusty. Каждый процесс работает в песочнице с собственной виртуальной памятью, которая управляется средствами MMU. Ядро распланировывает эти процессы на основе приоритетов; цикличность планирования задаётся защищённым синхронизатором тактов, все Trusty приложения имеют одинаковый приоритет.

Приложения для ОС Trusty могут быть написаны на C/C++.

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

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

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

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

Интересно использование чипов SoC (систем на кристалле). Подробная статья тут. это и есть ASIC с спец функциями. К примеру в устройствах Android используется этот чип для обеспечения безопасной среды и хранения ключей.

Пример системы на процессоре A9

Внешние доверенные устройства

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

Доверенный механизм ввода данных. Реализуется с помощью клавиатур ввода данных физически располагаемых на устройстве. Характерным примером являются так называемые «криптокалькуляторы», к примеру Ledger Nano S, на клавиатуре которых производится набор платежных реквизитов и затем на основе секрета устройства (или секрета платежной карты) формируется код подтверждения платежа. Основным недостатком решения является необходимость ввода данных вручную. В банковской сфере, для устранения этого неудобства, в устройство может быть добавлена функциональность хранения списка контрагентов.
Визуальный контроль данных, осуществляемый с помощью дисплея доверенного устройства. В отличии от первого способа, данные формируются в недоверенной среде, а затем отображаются на экране доверенного устройства. Корректность данных проверяет пользователь устройства. В случае подтверждения пользователем корректности данных, формируется код подтверждения.

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

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

Перспективы

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

Механизм TEE в мобильных устройствах:

0_1532266225014_Otkrytye_sistemy.SUBD_1(8049)_500.png

Источник: https://source.android.com/security/trusty/

@stil99 Спасибо, помогло при установки с "0", минут 10 и БЧ восстановлен.

Блок 1401917

Разработчикам создана раздача тестовых (DEV) монет, необходимых в тестировании API SmartHoldem без затрат настоящих монет.

Обозреватель блоков тестовой сети DEV Explorer

Делегатам - улучшенная безопасность нод А. Вы можете сгенерировать вторую парольную фразу к своему адресу, но на сервере использовать первую, что гарантирует полную безопасность в случае компроментации первой фразы. После активации Все дальнейшие исходящие операции адреса необходимо проводить при использовании двух фраз. Протестировано в DevNet. Комиссия включения второй фразы 5 STH.
Помните! В случае утери парольной фразы вы не сможете получить доступ к вашим активам!

Обновлен SmartHoldem API Wrapper при работе с транзакциями, идентификацией типа сети, подбор случайных нод.

Обновлен API JS в ветках mainnet & desktop wallet, исправления в валидации адреса и типов сетей (sidechains)

Обновлены скрипты faucet

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

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

Обновлена документация API SmartHoldem по API Wrapper и примерам использования.

@patinity да эта библиотека создана для упрощения взаимодействия с API SmartHoldem и дочерними blockchain. Библиотека постоянно дорабатывается и доабвляются новые функции.

Подпись сообщений может потребоваться при подтверждении владения конкретным адресом SmartHoldem без раскрытия самого приватного ключа. Результат проверки подписи имеет одно из значений: проверка пройдена, не пройдена.

К примеру при участии в ico вам может потребоваться подтверждение владения адресом, подпись контента в p2p сетях, авторство (в сочетании с хэшированием) или при авторизации на сайте поддерживающем API SmartHoldem. Либо при других операция где необходимо подтвердить владение адресом.

Подписание сообщения:

откройте SmartHoldem приложение выберите свой адрес > подпись сообщения нажмите ПОДПИСЬ укажите секретную фразу и сообщения вы получите запись с подписанным сообщением нажмите скопировать

пример результата

{"publickey":"03675c61dcc23eab75f9948c6510b54d34fced4a73d3c9f2132c76a29750e7a614","signature":"304402207d067ac09b1462289e43e701e43933580b195f40b643188e8e6330424db680de022027dff63053337a428cd8f04de675efb9aad57236c5acfad3c2b85ea7bf51efd3","message":"hello community"}

Теперь возможно проверить действительность подписавшего сообщение:

Проверка сообщения:

нажмите ПРОВЕРИТЬ укажите открытый ключ, подпись и сообщение появится сообщение о подтверждении подписи, если сообщение прошло проверку

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

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

@patinity в настоящее время ведется работа/иссследования по созданию виртуальной машины (vm) выполнения контрактов.

в качестве кандидатов языки: lua, node vm, c++ (ciyam) + пару эксзотических.

нам необходим на входе простой для понимания разработчиков язык контрактов, к примеру в lua возможно в формате js записать контракт (в отличии от солидити более понятен людям) и на выходе получить выполняемый в vm байткод.

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

К примеру EOS используют WASM на clang, напоминает vm nodejs, который слегка не безопасен в стандартной реализации (мое субъективное мнение).

0_1523646579162_sh_desktopwallet.jpg
Work on the official SmartHoldem Wallet continues. With each release, the functionality of the wallet is getting better and more usability for users. In this update SmartHoldem Wallet added +10 000 new lines of code.

New version of SmartHoldem Wallet 1.0.0 available https://github.com/smartholdem/smartholdem-wallet/releases

Added languages: Arabic, Korean, Serbian, Chinese (Taiwan), Japanese, Portuguese (Brazil).

Option - bind a purse to the trusted node ip.

Sending payment function with a message.

The experimental function of multi payments from a csv-file, up to 20 (the idea is taken from the old service webmoney - experimentally).

Customizable design of the user interface.

Management of networks and sidechains (experimentally, in progress).

Exporting Address Transactions to a File.

Updated version of electron to 1.8.4.

Updating the engine framework.

Fixed qr-code recognition (ntegration with uri apps is being developed SHIP-001).

The voting system is simplified (now it looks more convenient).

The function of recording into blockchain the second secret phrase to the address is added (use with caution, since after activation it is necessary to know 2 phrases).

The field for displaying a note in the table has been added to the transaction list.

The main Internet resources of the ecosystem have been added to the help menu.

Corrected shutdown screenshots work.

Improved application setup for windows (now a normal installer with a choice of installation path).

Update MacOs Installer.

Update Linux Installer.

More than minor 96 fixes.

Additional functionality and decentralized applications are planned in the next versions.

0_1523657632719_walletScreen.jpg

Простой пример отправки транзакции через PHP Curl с примечанием к платежу:

!Важно отправлять данные на доверенную ноду, т.е. на вашу.

<?php $url = 'http://node_ip:6100/api/transactions'; $data = json_encode((object) array( "secret" => "секретная фраза адреса отправителя", "amount" => 10000000, //0.1 STH в Satoshi "recipientId" => "Sa9JKodiNeM7tbYjxwEhvvG1kBczhQxTN3", //адрес получателя "vendorField" => "any message" // опциональное поле 64 байт )); $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_HTTPHEADER, array('Accept: application/json', 'Content-Type: application/json')); curl_setopt($ch, CURLOPT_HEADER, 0); curl_setopt($ch, CURLOPT_TIMEOUT, 30); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "PUT"); curl_setopt($ch, CURLOPT_POST, true); curl_setopt($ch, CURLOPT_POSTFIELDS, $data); $response = curl_exec($ch); curl_close($ch); $result = json_decode($response, true); //convert to array print_r($result); //show result

Результат выполнения при успехе примерно следующий:

Array ( [success] => 1 [transactionId] => 97fc4c43279a27e7c28a4058ce06219434a0b4f97e6bf5a12f9ebb41a739652a )

*При использовании двух парольных фраз добавьте поле secondSecret

Пример добавлен в документацию

Проблемы распространения децентрализованных сетей

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

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

Варианты мотивации:

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

2. интерес к контенту
Если сайт интересен в p2p сети, его посещают тысячи пиров, распространяя контент ресурса и поднимая скорость отдачи материалов. При росте сети, контент станет избыточен, для сокращения избыточности используем формулу m < N, где m - max число пиров для одинакового контента, N - всего пиров в сети. Дополнительно сократить дедубликацию контента возможно с помощью хэширования в ipfs, к примеру библиотека jquery.js отправленая в сеть ipfs будет доступна по ранее загруженному хэшу.

3. анонимность, безопасность, отсутствие цензурирования
В обычном интернете все ваши письма, переписка и личные данные доступны провайдерам.
В p2p сетях защищенных криптографией и дополнительными протоколами (tor, vpn, tls) данная проблема отсутствует, являясь мотивацией использования.

Исходя из некоторых исследований, понимание свободного интернета для большинства пользователей сводится к тому, что участники сети ощущая полную анонимность и безопасность ведут себя недостойно и неуважительно по отношению к другим участникам. Т.е. обычное дело написать "все кАзлы..", не используя действительный потенциал сети на 0.0001% и новых возможностей, однако адекватному человеку подобный контент неинтересно воспринимать. Соответственно необходимы новые методы взаимодействия с троллинг-контентом при отсутствии злого центрального админа.

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

Приватное облачное хранилище

Всем нам известно, централизованные облачные системы dropbox, google, apple и подобные имеют доступ к всем вашим данным в облаке, не мало известны факты о взломах подобных систем со всеми вытекающими последствиями.

Приватное децентрализованное облачное хранилище исключает недостатки систем на ручном управлении.

Входные параметры хранилища:

минимальное число поддерживающих пиров (5-10-15-100-N пиров) время хранения (1-3-6-12-24-240-N месяцев) объем (1-3-5-N Tb)

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

Умные контракты в децентрализованных сетях

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

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

Децентрализованная сеть может выступить как sidechain умным контрактам, неограничиваясь объемом выполняемой программы, неважно 1кб или сотни мегабайт ваш контракт, он будет выполняться и храниться.
В качестве доказательства детерминичности возможно использовать ссылку-указатель в формате хэша контракта. Т.е. все, что необходимо записать в блокчейн - специальную транзакцию в несколько байт связанную с контрактом p2p сети. Это существенно сократит издержки на поддержание контрактных систем в blockchain. Один из вариантов использование принципа приватного облачного хранилища.

К примеру контракт на проведение ICO не нуждается в вечном хранении, а лишь до его завершения и выполнения конечных автоматизированных условий - Temporary Smart Contracts.

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

По моему я задонатил куда надо😅 Мало что понял с выше описаного, так как несильно технически подкован, но это звучит очень мощно. У меня чуйка😉

Версия 0.0.3

Добавлена функция отправки транзакций с примечанием (сообщением) Добавлены ссылки на скачивание легкого кошелька (скачать, распаковать. запустить index.html)

https://onlinewallet.smartholdem.io/

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

В данном руководстве рассматривается метод приема платежей с примечанием к платежу (сообщением) в экосистеме SmartHoldem. Сервис использует 1 адрес, но для каждого пользователя генерируется уникальная строка.

Для простоты понимания в качестве бэкенда используется язык PHP.

В процессе участвуют: сервис (обменник) и пользователь (клиент).

Клиент

Со стороны клиента некий сервис - обменник, генерирует для клиента исходные данные.

0_1522740861038_service1.jpg

сумма к получению в меняемой монете (задаваемая клиентом) расчетный результат к получению по текущему курсу STH > COIN адрес для отправки STH (для всех один) уникальная строка сообщения (идентифицирует отправителя)

Здесь на стороне сервиса в backend генерируется уникальная строка для каждого пользователя и сохраняется в базу данных, к примеру таблица вида:
userid(int), msg(string)

<?php $msg = substr(md5(uniqid(microtime(), 1)) . getmypid(), 1, 8); // результат уникальная строка: 561559b2

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

0_1522742749392_wallet_v1.jpg

Сервис

Теперь в работу вступает backend сервиса, обработчик транзакций. Для простоты понимания будем использовать выполнения скрипта по crontab.

Создаем на стороне сервера php-файл, далее пропишем его на выполнение cron каждую минуту.

<?php $addr = 'Sg13BhANeairfS3o3w8N9sKaFrsht2bt4V'; //адрес проверки транзакций $limit = 25; //лимит выдачи транзакций $offset = 0; // смещение //сортируем выдачу транзакций по timestamp с помощью orderBy $url = 'http://your_node_ip:6100/api/transactions?recipientId='.$addr.'&orderBy=timestamp&offset=0'; //получаем данные и преобразуем в массив $tx = json_decode(file_get_contents($url),true); /* если транзакций более лимита, смещаем offset указатель выдачи транзакций и получаем последние $limit транзакций, т.к. транзакций может быть сотни тысяч */ if ($tx['count'] > $limit) { $offset = $tx['count'] - $limit; // расчет смещения $url = 'http://your_node_ip:6100/api/transactions?recipientId=Sg13BhANeairfS3o3w8N9sKaFrsht2bt4V&orderBy=timestamp&offset='.$offset; $tx = json_decode(file_get_contents($url),true); } // обрабатываем данные for ($i = 0; $i < count($tx['transactions']); $i++) { print "<br>amount:".$tx['transactions'][$i]['amount']. " timestamp:".$tx['transactions'][$i]['timestamp']. " msg:".$tx['transactions'][$i]['vendorField']. " senderId:".$tx['transactions'][$i]['senderId']. " Txid:".$tx['transactions'][$i]['id']; /* здесь выполняем необходимые проверки и операции записи в базу данных, к примеру добавляем баланс сохраняем в таблицу транзакций уникальные транзакции, которые и проверям при получении, к примеру txid, userid, timestamp, sum_sth, sum_coin */ /* помним, баланс выдается в сатоши, не забываем его преобразовать точными функциями */ $sumCOIN = bcdiv($tx['transactions'][$i]['amount'],100000000,8); $set['btc_sth'] = 1; //курс по отношению к STH $sumBTC = bcdiv($sumCOIN, $set['btc_sth'], 8); //расчитываем курс монеты }

Вот и все, транзакция обработана, операция выполнена.

Новые операции
+BTC за STH
1.28 BTC / 0.32000000 STH
03.04.18 09:59

пример не претендует на качество кода, он предназначен для базового понимания приема платежей.

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

P.S. Событийный подход мы рассмотрим в следующих публикациях.

P.P.S. Функция отправки сообщений будет доступна в версии кошелька 1.0 в ближайшие дни/неделю, с сотнями других дополнений и исправлений.

Здесь формируется список тем о расширении и развитии дополнительных протоколов SmartHoldem https://github.com/smartholdem/SHIPs

Меня тоже интересуют подробности по самиту.

@technol0g said in Переполнение диска:

df -h

Также благодарю за информацию. Почистил логи. Их размер у меня составлял 4,4 гига. Теперь доступно 69 гигов.

@TechnoL0g поддерживаю идею внедрения.

WOW, только сейчас заметил, что сайт smartholdem.io обновили. Круто, теперь он красивый и новомодный ) Правда не увидел ру версию