Это всё админы щиткойнов в биток бегут, не иначе...
Хз. Думаю это СМЕ двигает рынок вврх. Там цена дороже. Так всегда на росте.
Битстамп пылесос подключили кстати
Криптовалютная биржа Bitstamp стала первой, кто интегрировал решение Signet от Signature Bank, позволяющее институциональным клиентам совершать переводы в долларах США в режиме реального времени, 24/7.
https://t.me/forklog/12853Самое эпичное натягивание совы на глобус, которое я видел!
Почему не просто вертикальная линия вверх, где то на миллион, а?
Графики вообще не похожи, так можно что угодно на что угодно наложить.
Сказка на ночь - "Биткоин по $700 000 или боль невнимательного пользователя". На графике, как я полагаю, результат невнимательности пользователя в малоликвидном стакане. Пользователь решил купить btc за usd, не лимитным ордером, а по макету. Все было бы хорошо, да стаканы в этой паре еще скудны. Результат - цена взлетела до $700тыс. Пользователь скупил все что было. С одной стороны грустная история, а с другой есть пользователь который продал 0.004btc по $700к. Выводы: 1)Будьте внимательны с типом ордеров. 2)Всегда перепроверяйте что вы делаете, особенно на крупные суммы (это тот случай). 3) Стоять в стаканах бывает очень прибыльно.
П.С. Там сообщество валидаторов ТОН сегодня запускали.
https://freeton.org/https://www.youtube.com/watch?v=NrbvU5j-9YwAbstract Datagram Network Layer (ADNL)
Краеугольным камнем в создании сетевых протоколов TON является ADNL. Он позволяет всем узлам принимать определенные «сетевые идентификаторы», представленные 256-битными «абстрактными сетевыми адресами», и обмениваться данными (отправлять датаграмы друг другу, в качестве первого шага), используя только эти 256-битные сетевые адреса для идентификации отправителя и получатель. В частности, не нужно беспокоиться об адресах IPv4 или IPv6, номерах портов UDP и т.д., они скрыты абстрактным сетевым уровнем.
3.1.1. Абстрактные сетевые адреса
Абстрактный сетевой адрес, или просто адрес для краткости, является 256-битным целым числом равным 256-битному публичному ключу ECC. Этот публичный ключ может быть сгенерирован произвольно, таким образом создавая столько сетевых идентификаторов, сколько нравится узлу. Однако для получения (и расшифровки) сообщений, предназначенных для такого адреса, необходимо знать соответствующий закрытый ключ. Фактически, адрес не является открытым ключом; вместо этого это 256-битный хэш (Hash = sha256) сериализованного TL-объекта, который может описывать несколько типов открытых ключей и адресов в зависимости от его конструктора (первые четыре байта). В простейшем случае этот сериализованный TL-объект состоит из 4-байтового магического числа и 256-битного открытого ключа криптографии с эллиптической кривой (ECC); в этом случае адрес будет равен хешу этой 36-байтовой структуры. Однако можно вместо этого использовать 2048-битные ключи RSA или любую другую схему криптографии с открытыми ключами. Когда узел узнает абстрактный адрес другого узла, он также должен получить свой «образ» (т.е. сериализованный TL-объект, хэш которого равен этому абстрактному адресу), иначе он не сможет шифровать и отправлять датаграммы на этот адрес.
3.1.2. Сети более низкого уровня
Реализация UDP. С точки зрения почти всех сетевых компонентов TON, единственное, что существует, - это сеть (сетевой уровень абстрактных датаграмм), способная отправлять датаграмы с одного абстрактного адреса на другой. В принципе, абстрактный сетевой уровень датаграм (ADNL) может быть реализован в различных существующих сетевых технологиях. Однако мы собираемся реализовать его по протоколу UDP в сетях IPv4 / IPv6 (таких как Интернет или интрасети), с необязательным запасным вариантом TCP, если UDP недоступен.
3.1.3. Простой вариант использования ADNL по UDP
Простейший случай отправки датаграм с абстрактного адреса отправителя на любой другой абстрактный адрес (с известным изображением) может быть реализован следующим образом. Предположим, что отправитель каким-то образом знает IP-адрес и UDP-порт получателя, которому принадлежит абстрактный адрес назначения, и что и получатель, и отправитель используют абстрактные адреса, полученные из 256-битных открытых ключей ECC. В этом случае отправитель просто добавляет датаграм для отправки своей подписью ECC (выполненной с помощью своего закрытого ключа) и адресом своего источника. Результат шифруется открытым ключом получателя, встраивается в датаграму UDP и отправляется на известный IP-адрес и порт получателя. Поскольку первые 256 бит датаграмы UDP содержат абстрактный адрес получателя, получатель может определить, какой закрытый ключ следует использовать для расшифровки оставшейся части датаграмы. Только после этого раскрывается личность отправителя.
3.1.4. Менее безопасный способ, с адресом отправителя в тексте
Иногда недостаточно безопасной схемы, когда адреса получателя и отправителя хранятся в незашифрованном виде в дейтаграмме UDP; закрытый ключ отправителя и открытый ключ получателя объединяются вместе с помощью ECDH (эллиптическая кривая Диффи-Хеллмана) для генерации 256-битного общего секрета, который используется впоследствии, наряду со случайным 256-битным одноразовым номером, также включенным в незашифрованную часть, получить ключи AES, используемые для шифрования. Целостность может быть обеспечена, например, путем объединения хеша исходных данных открытого текста в открытый текст перед шифрованием. Преимущество этого подхода состоит в том, что если ожидается обмен более чем двумя датаграмами между двумя адресами, общий секрет может быть вычислен только один раз, а затем кэширован, тогда более медленные операции эллиптической кривой больше не будут требоваться для шифрования или дешифрования следующих датаграм.
3.1.5. Каналы и идентификаторы каналов
В простейшем случае первые 256 бит датаграммы UDP, несущей встроенную дейтаграмму TON ADNL, будут равны адресу получателя. Однако в целом они составляют идентификатор канала. Существуют разные типы каналов. Некоторые из них являются двухточечными; они создаются двумя сторонами, которые желают обмениваться большим количеством данных в будущем и генерировать общий секрет путем обмена несколькими пакетами, зашифрованными, путем запуска классической или эллиптической кривой Диффи-Хеллмана (если безопасность), или просто одна сторона генерирует случайный общий секрет и отправляет его другой стороне. После этого идентификатор канала извлекается из общего секрета в сочетании с некоторыми дополнительными данными (такими как адреса отправителя и получателя), например, путем хеширования, и этот идентификатор используется в качестве первых 256 битов датаграм UDP, переносящих данные, зашифрованные с помощью помощь этого общего секрета.
3.1.6. Канал как идентификатор туннеля
В общем, «канал» или «идентификатор канала» просто выбирает способ обработки входящей датаграммы UDP, известный получателю. Если канал является абстрактным адресом получателя, обработка выполняется, если канал является установленным двухточечным каналом, обработка состоит в расшифровке датаграммы с помощью общего секрета. В частности, идентификатор канала может фактически выбрать «туннель», когда непосредственный получатель просто пересылает полученное сообщение кому-то другому - фактическому получателю или другому прокси. Некоторые этапы шифрования или дешифрования (напоминающие «луковую маршрутизацию» или даже «чесночную маршрутизацию») могут быть выполнены по пути, и другой идентификатор канала может быть использован для перешифрованных переадресованных пакетов (например, одноранговая маршрутизация). Равноправный канал может использоваться для пересылки пакета следующему получателю на пути). Таким образом, некоторая поддержка «туннелирования» и «прокси» - что-то вроде того, что обеспечивается проектами TOR или I2P - может быть добавлена на уровне сетевого уровня абстрактных дейтаграмм TON, не затрагивая функциональность всех высших сетевые протоколы уровня TON, которые были бы независимы от такого дополнения. Эта возможность используется службой TON Proxy.
3.1.7. Нулевой канал и проблема начальной загрузки
Обычно TON ADNL будет иметь некоторую «таблицу соседей», содержащую информацию о других известных узлах, таких как их абстрактные адреса и их прообразы (то есть открытые ключи), а также их IP-адреса и порты UDP. Затем он будет постепенно расширять эту таблицу, используя информацию, полученную из этих известных узлов, в качестве ответов на специальные запросы, а иногда и удалять устаревшие записи. Однако, когда узел TON ADNL только запускается, может случиться так, что он не знает ни одного другого узла и может узнать только IP-адрес и UDP-порт узла, но не его абстрактный адрес. Это происходит, например, если легкий клиент не может получить доступ ни к одному из ранее кэшированных узлов и к любым узлам, жестко закодированным в программное обеспечение, и должен попросить пользователя ввести IP-адрес или DNS-домен узла, который необходимо разрешить через DNS. В этом случае узел будет отправлять пакеты на специальный «нулевой канал» рассматриваемого узла. Это не требует знания открытого ключа получателя (но сообщение все равно должно содержать личность и подпись отправителя), поэтому сообщение передается без шифрования. Обычно его следует использовать только для получения идентификатора (возможно, единовременного идентификатора, созданного специально для этой цели) получателя и затем для начала более безопасной связи. Как только хотя бы один узел известен, можно легко заполнить «таблицу соседей» и «таблицу маршрутизации» большим количеством записей, изучая их на основе ответов на специальные запросы, отправленные на уже известные узлы. Не все узлы требуются для обработки дейтаграмм, отправленных на нулевой канал, но те, которые используются для начальной загрузки легких клиентов, должны поддерживать эту функцию.
3.1.8. TCP-подобный стриминговый протокол поверх ADNL
ADNL, являющийся малым протоколом датаграмм на основе 256-битных абстрактных адресов может использоваться в качестве основы для более сложных сетевых протоколов. Можно создать, например, TCP-подобный потоковый протокол, используя ADNL в качестве абстрактной замены IP. Однако большинству компонентов проекта TON такой потоковый протокол не нужен.
3.1.9. RLDP или надежный протокол больших датаграмм поверх ADNL
Надежный протокол датаграмм произвольного размера, построенный на ADNL, называемый RLDP, используется вместо протокола, подобного TCP. Этот надежный протокол датаграмм может использоваться, например, для отправки запросов RPC удаленным хостам и получения от них ответов.
https://tontalk.org/threads/201/
Poll
