Nice UI! But what's up with mobile version?

У меня была идея сделать анализатор паттернов по принципу computer vision (за основу брал mnist на tensorflow). Представить известный паттерн свечей (например десятиминутный) в виде условной "картинки", состоящей из параметров которые описывают свечи (Open Close High Low) и пробовать классифицировать по шкале того к чему это в итоге ведет (сильный/слабый рост/падение) и обучал это на свечках, которые я яростно парсил с бинанса. Получилось чудовище франкенштейна которое я поленился допиливать после эпических фэйлов и массы разочарований в своих скиллах

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

Я бы хотел сказать что "да это все легко", но это не так, точно не мне. Тут намешано очень много, хоть и не сложной, но разной и в значительной степени абстрактной математики (тут и линал, и теория групп и множеств и геометрия). Мне вот интересно какая голова это все собрала в ECC и, главное, донесла до остальных. Цепочка логических выводов очень тонкая и тянется через одну теорию в другую. Я очень много опустил - куча теорем с доказательствами, которые тянут за собой огромный пласт базовых знаний, которые, я порядком подзабыл.

Команды такой нет. Теоретически можно разобрать wallet.dat как базу данных (бёркли дб), но я сам не осилил.

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

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

Дело в том, что если взять неразрывную кривую и модель приватный ключ - это A, публичный ключ это C = A * B, то резултат произведения A*B может быть очень больших размеров, и их трудно будет описывать в машинном коде.

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

Разумным ограничением будет переопределение кривой не в евклидовом пространстве, а в простренстве конечного числа целых чисел, подчиняющихся какому-либо правилу, которое не позволяет координатам ни при каких условиях превысить заданной границы (чтобы длина нашего публичного ключа не росла бесконечно). Это легко сделать, если во первых ограничить себя только целыми числами и вспомнить про операцию mod (остаток от деления) на какое-нибудь простое число. Почему простое? Потому что использование простого числа дает возможность определить операцию деления через умножение, поскольку результатов деления может быть ровно два - 1 и само число). Итак уравнение элептической кривой (которое записано как Y^2=X3+AX+B) мы перепишем в форме:
Y^2 mod P = (X^3 + AX + B) mod P

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

Решения такого уравнения, например, для P = 3, А = 0 B =0  будут выглядеть примерно так: (1,1), (2,2), (3,0) и потом, если подставлять X>3, точки на плоскости начинают повторяться, всегда внутри квадрата 0-3 - советую посчитать решения руками для разных наборов P,A и B и нарисовать в тетрадке, чтобы понять, что из-за целочисленного деления - не важно какое х и y я буду брать - точек строго ограниченное количество и они симметричны относительно оси Х, а самое главное - точек всегда ровно P (в моем примере - 3). Если мы вместо P = 3 возьмем P = 5 - точек будет 5. 

Короткий ответ:


1. Множитель конечной группы P выбран последним простым числом меньше чем 2^256  :

p = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFFC2F (115792089237316195423570985008687907853269984665640564039457584007908834671663)

Это и есть порядок группы, если брать все элементы из группы. Однако, все решили не брать, а брать только элементы начиная с определенной точки G (я писал - я хз как именно эту точку выбрали). То количество точек станет меньше, и их останется

ffffffff ffffffff ffffffff fffffffe baaedce6 af48a03b bfd25e8c d0364141  (115792089237316195423570985008687907852837564279074904382605163141518161494337)

тоже простое число, но чутка поменьше, потому что у кривой "откусили" начало.



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


2. Наверное логичнее задавать порядок группы изначально чем его считать. Если посмотреть на уравнение которым описывается кривая - оно содержит в себе mod P, вот P - это и есть простое число, которое определяет кол-во точек и порядок группы. Если группу урезать, то кол-во точек уменьшится.

Группа это пространство чего-либо (например пространство векторов, или точек или слонов), для которых вы определяете операцию сложения. В применении к элептической кривой группа - это множество наборов из трех точек, лежащих на прямой в точке пересечения этой прямой с кривой. "Сумма" этих точек равна нулю (это определение их сложения, которое обладает всеми свойствами сложения). Если взять все-все точки кривой - группа получится бесконечной (т.к. на ней бесконечное кол-во троек точек дающих по определению сложения в группе - ноль. У бесконечных групп - порядок группы не определен. Но мы можем взять не все точки кривой, а только некоторое конечное количество точек. Тогда порядок группы станет конечным и будет определяться правилом выбора тех точек которые мы выберем для построения группы. То есть мы берем из всех "троеточий" только некоторые, которые удовлетворяют конкретному правилу (например берем только троекточие от пересечения с осью Х). Тогда наша группа будет состоять из одного троеточия и ее порядок будет равен 1.

О том как получить порядок группы над конечном полем я напишу чуть позже (сначала разберемся с тем что такое поле). Но сразу спойлер - почему Base Point в ненаглядном взяли такой какой взяли - я не скажу. Примерно вот так это мотивирует светоч:

https://bitcointalk.org/index.php?topic=553091.msg6020830#msg6020830

А сейчас - спать пора.

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

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

Например сложение целых чисел - мы все знаем. Оно обладает свойством коммутативности, ассоциативности и подчиняется правилу сложения.

Сложение векторов в пространстве - уже сильно отличается от сложения целых чисел, хотя так же коммутативно и ассоциативно (т.е. фундаментально без разницы что с чем складывать и в каком порядке), однако правила сложения уже несколько отличаются, т.к. вектор описывается не одним числом а набором чисел (в зависимости от размерности пространства). На плоскости вектор можно описать двумя числами - координатами конца стрелочки протянутой из нуля. Например у вектора тянущегося под 45% направо вверх будет запись (1,1) или (2,2) и т.п. Умножение вектора на число - это помножение всех "координат", его описывающих на число (если это нарисовать, то это будет выглядеть как удлиннение стрелочки без изменения направления). Умножив вектор (1,1) на 2 получим вектор (2,2).


Сложение в применении к элептической криваой определяется совсем иначе - а именно как поиск решения системы уравнений и инвертирования его знака по оси Y.  Одно уравнение описывает кривую, другое - прямую, проведенные через две точки - но это вы уже видимо поняли.
Складывать, разумеется можно только те точки, которые УЖЕ находятся на кривой (т.е. являются решением уравнения кривой при фиксации X или Y в уравнении кривой. Сложить точки с координатами (1,1) и (0,1) на криваой не получится, т.к. они не лежат на кривой ).

Возникает резонный вопрос - что делать в тех случаях, когда точку надо сложить с самой собой, чтобы через такое сложение можно определить умножение? Сложение точки с самой собой предполагает такую прямую, которая проходит через эту едиственную точку на бесконечно малом участке кривой, то есть - касательную. А уравнение касательной, как известно легко вычисляется, расчетом производной. То есть если мы имеем произвольную точку на кривой, мы считаем ПРОИЗВОДНУЮ элиптического уравнения в этой точке (производная - это уравнение прямой). Потом мы решаем систему уравнений этой прямой и уравнения кривой, инвертируем по знаку и получаем ту точку, которая будет "суммой" A+A или иными словами A*2. Вот так определяется умножение. Чтобы посчитать 3*А - можно прибавить к 2A еще один A.

Как видите, если вчитаться в этот абзац "умножение" на кривой это адский гемморой, но он несколько облегчается, ели организованно использовать память и свести умножение к сложению. Например чтобы посчитать 9A можно посчитать 2A+2A = 4A, потом посчитать 4A+4A = 8A а потом прибавить 1А.

Если А это произвольное число длинной в 256 бит (~10^77), то, чтобы посчитать его произведение на любое другое число (НА КРИВОЙ) потребуется операций сложения не более чем 510. (Если очень надо - можно это доказать).

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

Теперь о криптографии. Допустим есть A - это старотовая точка. И есть B - множитель. Есть так же произведение A * B = C.
Если я вам дам С, то сможете ли вы узнать сколько раз B сложили с самим собой (A), чтобы получить С? Оказывается, что нет, потому что не определено (во всяком случае на данный момент) операции деления и единственная опция поиска A это тупо складывать B с самим собой в надежде получить С.

Ну вот тут мы и подходим к шифрованию.
в моем примере A - это ваш приватный ключ, С - это ваш публичный ключ а B - это стартовая точка на кривой, по которой вы начинаете свое путешествие из точки A в точку C, складывая B c самим собой по правилу сложения которое я описал выше.  

Надо глубже, или так понятно?

Я вот читаю ваши посты - и вижу что вы в теме уже по меркам большинства очень и очень давно. Как, блин, так вышло, что ваш проект мимо форума прошел?

Насчет Apple ID суть такая:

Эппл обязывает разработчиков встраивать в свой апп механизм восстановления покупок. Они не дают конкретного метода решения проблемы, но дают начальные условия - если человек с apple ID сделал какую-то покупку, он эту покупку обязан восстановить на другом девайсе. Покупок 2 типа - "consumable" и "permanent" (подписки есть еще двух типов, но это, наверное, не про вас - а если про вас - то это примерно то же что и 2й тип покупок, тока требует бабла по таймеру).

Consumable - это вещи которые купил и заюзал - тут вам придутся вести список того воспользовался этот эппл ID шмоткой или нет. Например такую покупку можно оформить так "Покупая это вы добавляете 200 кристаллов на учетку №XXX". После релогина - покупка видна в виде квитанции "200 кристаллов добавлено на учетку №XXX". Если у вас есть бэкэнд ( что-то мне говорит о том, что он есть =) ) то проблем не будет -восстановление покупки обеспечивается бэком.

Permanent - это что-то что дает постоянный эффект (например отключение рекламы). Тут без трекинга Apple ID не обойтись, т.к. отключение рекламы должно работать не зависимо от того, какой внутреигровой акк пользователь открывает. Но такие покупки обычно касаются аппов в целом, а если нет - то придется таки сохранять apple id всех купивших на бэке, чтобы можно было получить купленный апгрейд подтвердив свою учетку эппл в любом аккаунте на который зашли с девайса.

(Я это ботал три года назад - может быть все уже совсем не так или я в маразме уже, так что могу ошибаться)

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

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

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

Почитайте про лайтнинг - это круче.

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

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

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

Ну они как бы делали заявления, что их койн это не биткойнкэш (что характерно и faketoshi и bitcoin judas), а совершенно новая тема. Тикеры, то конечно биржи присваивают, но тут явно же разработчики подчеркивали, что не хотят быть продолжением старой цепи а пилят новую. Если бы они были последовательными в своих заявлениях то оба сделали бы реплей протекшн на старый кэш и не было бы проблем.

Там на сайте пантеры забавная такая фраза:


У кого есть аккредитация?

МММ

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

Нет, если есть replay proitection.


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

Да. Насчет replay protection amaclin правду говорит. Действительно - во всех трех сетях у одного (достаточно старого) приватного ключа одинаковые балансы, т.к. до прошлого лета это был один и тот же блокчейн. Replay transaction охзначает что одна и та же транзакциябудет валидна в двух совершенно разных сетях. Например если вы с адреса  A кидаете 1 SV На адрес B, точна такая-же транзакция будет абсолютно валидна в сети ABC. Если вы попробуете расплатиться с не чистым на руку получателем шитками SV, то он может и с большой долей вероятности прикарманить и шитк ABC.

Replay protection это изменения в протоколе, которые делают не валидными транзакции одной сети в другой. Обычно, нормальные взрослые люди, решившие форкнуться делают replay protection, чтобы не сеять хаос в первое время после форка, однако обремененные безудержным ЧСВ Craig Wright и Роджер Вер не стали делать replay protection изначально. Существует ряд методов защитить свои шиткойны от возможности реплея (например поспендив их в разных сетях на разные подконтрольные адреса примерно одновременно или то что предлагает амаклин).