Сначала был потоп, и один язык.
Потом люди решили, что им нужна Вавилонская Башня и появились разные языки.
Затем в паспорте ввели графу "национальность", потом появилось понятие нации, после появился вообще нацизм и вторая мировая.
После второй мировой, по итогам Ялтинской Конференции было создано ООН.
И была принята "Всеобщая декларация ООН о правах человека".
И вот в самой аббревиатуре ООН и остались эти нации.

Вообще, я так понимаю, разобщённость нужна была тогда, чтобы люди не городили всякую хрень, вроде этой кривой башни.
Пирамидостроители в Египте и то качественнее работали. Пирамиды вон до сих пор стоят.
А тут, в крипте, одна пирамида офигительнее другой,
один скам лучше другого, памп-дамп, делист, и сидят потом без объёмов торгов, со своим неликвидным премайном. Лол.
Если бы все разговаривали на одном языке, вроде "логики предикатов первого порядка", то по мере ускорения самоорганизации модулей интеллектуальных,
могло бы породиться нечто такое,
что так запампилось бы, а потом так задампилось, что ну его нафиг.
Ну ты понял... А так нации и всё. И множество кривых проектов на разных языках.
Каждый кулик своё болото хвалит.
И сидишь себе, просто читаешь исходники, ржёшь с этой ихней альтоты, и шортишь её, и сливаешь на дампе.
ЫХХЫХХЫХ.

Я так изначально и предполагал, поэтому я и написал внизу первого поста о том,
что сами биткоины - не нужны для использования цифровой подписи.
Биткоин-адрес, именно от кошелька bitcoin-core - тоже как таковой не нужен. Не нужно его дампить и куда-то вводить.
Это может быть любой альткоин-адрес. Да и это не обязательно.
Ведь в адресе, важна здесь - сама уникальность его, как идентификатора для пользователя (он же и есть адрес),
ну и соответствие идентификатора - какому-то пользователю (по ассоциативной хэш-таблице, на сервере, например).
И альткоин для этого отдельный, делать не надо. Вообще блокчейн не нужен. Даже Base58Check не обязательно, и WIF-формат.
Просто работает ECDSA.

Может быть реализована - автоподпись, скриптами, на клиенте.
А обмен инфой может происходить даже после обрыва соединения.

Ну вот смотри, тут адрес не указан:
Однако если вставить это сообщение сюда, то адрес - он извлекается из цифровой подписи.



Ну, я уже писал, что не обязательно использовать приватные ключи и адреса именно биткоина,
и именно те, на которых что-то лежит. Монеты держать на адресах вообще не обязательно.
Не обязательно вообще использовать WIF и кодировку Base58Check.
Ведь приватные и публичные ключи - это функционал алгоритма ECDSA.
Но так как мы на bitcointalk, и так как многие используют биткоин,
то наверняка какого-нибудь скрипта или либы, вроде bitcoinsig.js
было бы достаточно для реализации такой авторизации,
более того, если бы повсеместно она использвалась,
то прикинь какой пиар был бы - для самого биткоина

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

---

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

Регистрация - генерация аккаунта.
1. Юзер впервые заходит на сайт и нажимает кнопку "Регистрация".
2. Там - два варианта. Либо "Создать новый аккаунт" (генерация), либо "Импортирвать существующий" (импорт).
3. Юзер выбирает первый вариант - "генерацию".
4. Сервер вгружает ему скрипты для генерации адреса и подписи сообщений.
5. Юзер вводит username/password. При вводе username - сервер проверяет username на уникальность.
Если username уникальный, и такого нет на сервере, то проверяется пароль. Ну, чтобы криптостойкий был.
username - отправляется на сервер, и сохраняется на сервере, в ответ, сервер генерирует рандом для подписи, и тоже его сохраняет.
6. Затем даётся команда на локальную генерацию ключа и адреса, на стороне клиента.
При этом, скрипт генерирует ему private key, получает с него адрес,
тут же - конвертирует privkey в seed (здесь есть легко-запоминающаяся кодировка "poetry"), и просит пользователя записать seed.
Seed этот - сохраняется в LocalStorage, в браузере клиента - и шифруется криптостойким паролем.
7. После этого, опять же, локально, на стороне клиента - подписывается рандом, выданный сервером,
и подписанное сообщение - отправляется на сервер. Сервер проверяет подпись, сравнивает рандом в тексте подписанного сообщения со сгенерированным рандомом, и выданным клиенту. В случае успешной проверки цифровой подписи,
сервер на выходе имеет сгенерированный адрес клиента.
Этот адрес сервер пишет - в ассоциативную хэш-таблицу, связывая его с username.

Авторизация.
1. Юзер пытается войти, и нажимает кнопку "Вход в аккаунт".
2. В cookies висит его username, в LocalStorage - зашифрованный паролем seed.
3. Юзер просто вводит пароль, и входит в аккаунт. После ввода пароля - расшифровывается seed,
и юзер уже может, через цифровую подпись и проверку её - может работать с сервером от имени его usernamе,
привязаному на сервере - к адресу подписанта сообщений.

Импорт аккаунта.
1. Предположим, юзер зачистил cookies и LocalStorage.
2. Юзер пытается зарегистрировать аккаунт снова. Он нажимает "Регистрация", но вместо генерации аккаунта - "Импортирвать существующий".
3. Сервер выгружает всё те же скрипты для генерации адреса.
4. Но вместо генерации, он просто вводит записанный у него ранее, seed, и импортирует существующий аккаунт.

Этот же вариант может быть доступен, если юзер вводит username,
но этот username - не уникален, и на сервере уже есть ассоциативная запись его с каким-либо адресом.
Тогда, сервер может показать ему огрызок адреса, ассоциированного с username (или даже весь адрес),
и возможно юзер сразу же вспомнит о том, где лежит его seed от этого адреса.

Иначе - можно регистрировать только другой username. И если seed утерян, то доступ к старому - утерян навсегда.

---

Вообще, всё это уже реализовано в waves-client и waves-lite-client.
Но как оно работает - мало кто знает,
и вряд-ли сможет реализовать подобное у себя на сайте,
а уж тем более стандартизировать всё это дело - для повсеместного внедрения.
Поэтому лепят всякие формы c кучей полей, и просят потом KYC, телефоны подвязывать,
мордой на камеру светить, и всякое такое,
даже где-то видел верификацию адреса,
где письмо по реальной почте приходит и надо код потом ввести с бумаги...

Можно ли вывести с okex.com без прохождения мерзотного KYC?

P.S.: Думал что скам, но просто нагуглил чей-то паспорт, проверил по номеру его - всё чисто. Залил - прошёл этот KYC.
Ну и просто вывел наконец оттуда - СВОЮ эту, крипту.

А там нету - мерзотного KYC?

Почему ещё в coinomat'e нет USDT?

Завёл 110 USDT на okex.com купил аж там эти WAVES'ы, а вывести их - нельзя.
Скам какой-то, походу. Завести без проблем можно, а с выводом проблемы...
Просят какие-то KYC. Ну, там, документы слать всякие личные, телефон подвязывать...
Конечно же я не буду проходить это дерьмо, мне рекламные SMS-ки от биржи не нужны,
а ещё я видел, что биржи торгуют личными данными...
В общем, на бирже зависло 81.0693897 WAVES.
Могу продать свой акк там - в обмен на эти WAVES'ы.

P.S.: Просто нагуглил в гугле, по картинкам, чей-то паспорт,
проверил его действительность по номеру, он оказался действительным.
Ввёл данные получил KYC1 LEVEL этот ихний, и сразу же вывел оттуда, эти свои WAVES'ы.
А то уж думал, за скам такой, эту биржу - в файл в hosts добавить, замкнув домен на 127.0.0.1,
ну, чтоб не напороться в будущем, лол.

Нет. Механизм эмиссии фиата централизирован.
Вот если бы печатные станки для печати евро-баксов были портативными,
сами печатались 3d-принтерами, а их исходники были открыты и висели в открытом доступе в децентрализованных сетях - тогда да.
А так...

Сейчас 2019-й год. 2032 минус 2019 - равно 13.
За 13 лет, про доллар вряд-ли забудут, и так как ты писал выше: "будут носители, будет информация", вот она и будет.
В данном случае, носителями информации являются нейросети в мозгу человека,
а долговременная память может хранить инфу в воспоминаниях 80-летней давности.
Однако, вот, про купоно-карбованцы, почему-то быстро позабыли.  

У TOX'a нет центрального сервера, это p2p сеть.
Но есть сервисы ToxDNS, вроде https://toxme.io/
Да, такие сервисы - имеют центр, в виде серверов,
но они имеют открытый исходник, и могут быть подняты на любом хосте.
Нужны они для того, чтобы длинный ToxID контакта - кодировать коротким,
уникальным и легко-запоминающемся именем, вроде user_vasya.

Любая. Достаточно сохранить на 15 лет - исходный код, копию скомпилированного кошелька, и одну лишь копию блокчейна,
чтобы в любой момент, снова, развернуть из неё mainnet и разнести блокчейн на ноды в процессе синхронизации.

Нафига взял тему для диплома, если нифига не шаришь? Тему тебе дали выбрать, а список литературы не дали что-ли?

ERC-20 токен на блокчейне Ethereum, можно создать за 20 минут.
Сами по себе токены нифига не стоят, до тех пор пока они не торгуются.
Так как ценность - понятие субъективное, о чём ещё Карл Менгер догадался,
то в процессе торгов, в зависимости от объёма торгов, устанавливается равновесная цена.
Так как объёмы торгов могут быть не на одной бирже, а на множестве бирж, и складываться из них,
то таким образом формируется суммарный объём торгов, и как следствие - среднерыночная равновесная цена,
сглаживаемая по мере проведения межбиржевой торговли.

Но ничто не мешает собрать бабос в некий фонд, скажем 100 килобаксов,
и обеспечить 1000000 токенов по 10 центов этими стами килобаксами.
Таким образом, капитализация токенов - будет равна ровно 100 килобаксов, а цена на каждый - 10 центов
(100000 $/ 1000000 токен = 0.1 $/за токен).
Вопрос только в том, реальна ли эта капитализация, то есть можно ли будет,
эти токены обменять, в любой момент на деньги или нет?
Ведь деньги можно разворовать, распилить и откатить, их можно не дать (не поставить стакан на закуп на бирже). А ещё, они горят.
А вот токены фиг тыбришь, они криптографией криптографической закриптованы.
Ну и да... Ещё... Пользователи, то есть держатели токенов - они могут терять приватные ключи свои, и даже умирать,
а это значит, что за деньгами они могут не прийти никогда.
В таком случае, определённое количество токенов просто выпадает из циркуляции,
а капитал, обеспечивающий капитализацию токенов - будет находиться в некоем фонде,
и главное чтобы его не прожрали там, и не скрысили - этот долбанный капитал.
В таком случае, если капитал сохраняется, то цена на циркулирующие токены - она может повышаться,
так как определённое количество токенов - выпадает из циркуляции, при утере ключей, и их никто никогда не купит,
а капитализация системы - сохраняется не столко для всех токенов, сколько для токенов - находящихся в циркуляции.

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

Годно!
Я примерно это и предложил, но я предложил просто вырезать транзы при автооптимизации блокчейна.
Надо будет исходник форкнуть и white-paper качнуть, и глянуть как там мусор вырезается у паскаль-коина,
а то гляжу, как монета, он может кануть в небытиё,
а вместе с ней и все эти наработки...

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

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

Можно синхронизировать короткий блокчейн, после автооптимизации,
а в первый блок засунуть magnet-ccылку со старым блокчейном,
в виде bootstrap.dat, который можно было бы прогрузить, пропарсить и извлечь историю транзакций,
или даже развернуть на ноде, и прокинуть API во вне, чтобы по нему можно было искать и выгружать транзакции,
а также выгружать блоки по отдельности и добавлять транзакции из них.
Но... Тогда, старый блокчейн, в виде архива или bootstrap.dat - надо будет залить в torrent,
чтобы по magnet-ссылке можно было его вытянуть оттуда.
И это всё дело должен кто-то сидировать. Дата-центр какой-нибудь, например.
Но, если это распределить между юзерами в сети p2p, то да, нужна память и плата за память.
Но есть децентрализованные хранилища, наподобие StorJ и SiaCoin. Там, майнинг - жёсткими дисками производится.

Изначальная синхронизация может долго идти, да, так как нужно проверить каждый блок, и всю цепочку.
И хранить весь блокчейн не очень удобно... Но у биткоина есть режим prune, где можно задать например 500 МБайт для блокчейна, и не больше.
Тогда, размер блокчейна - уменьшается, так как предыдущее блоки просто проверяются, а затем - усекаются и не сохраняются.
Для ускорения валидации - есть checkpoints. Они и в исходнике есть.
Это хэши блоков, которые корректны, а значит их не нужно проверять.
Если при валидации софтина натыкается на этот хэш, она не проверяет все блоки до него,
а просто с блока с этим хэшем начинает валидацию и уже - до конца блокчейна.

Ну, потратится чуток электричества, но не так же много, как при вычислении хэшей
со сложностью в десяток триллионов, при хэшрейте в несколько десятков экзахэшей/сек.
Выполнение заданий нужно разве что чтобы загрузить железо, чтобы не было мультов.
Пока выполняются задания и прёт трафик с результатами их выполнения - есть гарантия того, что это майнер,
а не мульт. Это надо для того, чтобы на одном компе не сгенерировали миллиард адресов, и не подключили их под видом миллиарда клиентов,
и не начали майнить получая миллиард наград за миллиард блоков - на миллиард адресов. Понял, да?
А что вычислять - ну не знаю, что актуальное, то и вычислять.
Думаю может быть достигнут какой-то консенсус в децентрализованной сети.
Так, например, в сети Binarium, какой бы децентрализованной она не была,
но там автоматически достигается некий консенсус, о выборе текущего алгоритма майнинга,
притом, что сам этот алгоритм - многозначный, а сама монета имеет вшитый мультиалго-майнинг, для защиты от ASIC'ов.

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

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

Сферу Дайсона сделайте, да и всё. А охлаждать можно лазерами.

Изначально, речь шла о авторизации на сайтах. Сайты - хостятся на сервере. Потому что архитектура «Клиент — сервер».

Глянь, как устроен и уже давно работает - ZeroNet.
Там сайты на жестких дисках хранятся, доступ к сайту осуществляется по адресу, подобному адресу биткоина.

Глянь, как устроен и уже давно работает - TOX.
Он - p2p и можно общаться без интернета - даже в LAN.
Там тоже генерируются два ключа - приватный и публичный.
Из приватного ключа - получается публичный. Шифрование - асимметричное, при помощи библиотеки NaCl (libsodium).
При этом, в идентификатор пользователя TOX, в его ToxID - входит, отчасти - публичный ключ
(наряду с неким значением NoSpam, которое не знает контакт, которого добавил этот пользователь, и XOR-checksum).
Вот тут можешь потыкать либу js-nacl.

Опять же, скорее напоминает вышеупомянутый ZeroNet, но там, скорее,
статичные странички хостятся, а не динамические.
И для обновления сайта - нужно ждать синхронизации инфы ещё и в децентрализованной сети.

Вот тут можно создавать комнаты, без всякой регистрации: https://webchat.freenode.net/
Это - технология IRC.

А постойте, лизинг же можно отменить в любой момент...
Что если кто-то поставил в Leasing, эти WAVES выданы в кредит под маржу, из этих WAVES, что удерживаются в Leasing,
но внезапно кто-то взял и снял WAVES c лизинга, нажатием кнопки отмены этого лизинга?
Отмена лизинга, означала бы немедленное требование кредитором - возврата кредита,
с моментальным закрытием рискованной позиции (с кредитным плечом), из-за недостатка кредитного обеспечения,
и это была бы ликвидация не по Stop Loss, и не по Take Profit.
Но принудительное закрытие позиции на BITMEX'e, оно может быть осуществлено,
только по заранее определённой - цене ликвидации,
и только если до определённого уровня дойдёт рыночная цена,
либо если сам трейдер установит другой, свой - Stop Loss или же Take Profit.
А тут получается что цена ликвидации двигалась бы. 
Но... На Bitmex'e, цена ликвидации рассчитывается в соответствии с балансом у трейдера,
то есть именно этот баланс покрывает маржу (кредит для кредитного плеча).
Можно было бы так же само, замкнуть кредит на баланс трейдера, как на BITMEX'e,
и возвращать его кредитору, либо при закрытии позиции самим трейдером, либо при ликвидации этой позиции.
Однако до тех пор, пока позиция висит, кредиторы не могли бы вернуть выданный кредит (закрыть Leasing),
и ждали бы закрытия позиции трейдером, либо с прибылью, либо с убытком,
либо ликвидации этой позиции по стопу, у трейдера, взявшего кредит.
То есть, это был бы совсем другой Leasing, а не тот, что для майнинга LPOS.
Его нельзя было бы закрыть в любой момент.
При этом, если трейдер открылся успешно, то выданные в кредит монеты
могли бы быть куплены-проданы им же, реально на рынке - тоже успешно,
принося тем самым прибыль не только трейдеру, но и кредиторам.
Если же трейдер открылся неуспешно, затем был долгий флэт, а потом у него выбило стоп,
то кредиторы просто могли бы вернуть кредит свой, через долгое время (время флэта),
и вернуть его через время, после закрытия позиции неуспешного трейдера, в результате ликвидации позиции,
и после выгорания баланса - у него, при этой ликвидации.

Как вам? Можно ли реализовать подобное, в коде?

А что там их писать, эти скрипты?
Работа с цифровыми подписями - уже написана на JavaScript тут исходник.
Это вкладки Sign и Verify в brainwallet.
При этом, для подписи сообщений и проверки цифровой подписи - не нужно держать монеты на балансе.
Просто работает алгоритм ECDSA. Он может работать локально, и без Интернета.

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

---

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

Как вариант, для решения проблемы мультов - могло бы использоваться то же 2FA (двухфакторная аутентификация),
в котором 2FA Security Key - динамический,
и зависит от значения ( hash(client_address) XOR hash(server_privkey) ).
Но это уже отдельный модуль, и да, на стороне сервера.

Поставь себе TOX. Он работает в LAN.

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

Если у майнера ферма из ASIC, и он желает подтвердить в первую очередь - свою транзакцию,
я считаю что целесообразным было бы самостоятельное управление mempool'ом,
чтобы он решал какие транзакции включить в свой блок, а какие не включить.

Также, немного нецелесообразной является генерация пустых блоков, с начислением одной лишь награды за блок - майнеру.
Я считаю, что лучше бы чтобы сложность майнинга падала в ноль автоматически,
при отсутствии транзакций в сети некоторое время,
но при этом, чтобы запускался майнинг на нодах только когда в mempool есть n-ное число транзакций,
либо если одна транзакция висит чуть дольше чем время блоктайма.
POW-майнинг жрёт много электричества, поэтому POS,
а чтобы эмиссия не росла, и длина блокчейна - то POS за комиссии от транзакций, и без пустых блоков.

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

Хотя я и отношусь ко всему этому скептически,
просто потому что люди ничего не решают в объективной реальности,
но всё-же, давайте рассмотрим эту идею подробнее.

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

То есть, грубо говоря, тот, у кого есть монеты - имеет право голоса.

Как это проверить? Ну баланс по адресу можно проверить через block-explorer.
Дальше. А как убедиться, ты имеешь дело с владельцем этих монет?
А есть возможность создания цифровой подписи приватным ключём от адреса.
и возможность проверки этой цифровой подписи.
После проверки, на выходе - адрес подписанта.
А по адресу уже, в блокчейне - можно проверить баланс.
Наличие цифровой подписи - говорит о том, что у владельца адреса есть приватный ключ,
а наличие монет на балансе адреса в блокчейне, говорит о том, что это не просто сгенерированный адрес, а адрес владельца монет.
При ассоциировании права на владение монетами с правом голоса, очевидно, что сообщение подписал избиратель.
А если этим сообщением является бюллетень, очевидно, что это ЕГО голос.
Голос, может быть оформлен в виде транзакции, и также упакован в блокчейн.
Тогда, по принципу неизрасходованных выходов, голос будет один и только один.
Также, голос можно было бы и изменить, как меняются значения записей DNS в криптовалюте NameCoin.
Обновление данных вписанных в блокчейн предыдущей транзакцией - просто
происходит включением ещё одной отдельной транзакции с новыми данными.

Поэтому, ещё, я оставлю вам VoteCoin.
Как монета - он уже всё, её уже вымайнили и задампали в дно.
Но исходник открыт, можете форкнуть, да посмотреть чё да как там...

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

Да и много чё ещё продумать надо бы, это только наброски.

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

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

Вот такое HTTP-API - можно было бы внутрь ВСЕХ нод встроить, как у тех же WAVES, что я и показал выше.
Именно HTTP/HTTPS. Чтобы не надо было код писать всякий, и чтобы любая домохозяйка могла разобраться с этим.
То есть, чтобы вот... Заходишь, например, куда-нибудь сюда: https://bitnodes.earn.com/ и видишь там 10000 нод биткоина...
IP:PORT, IP:PORT, и т.д...
Или например просто в консоли Bitcoin Core вводишь команду getpeerinfo,
копируешь любой пир оттуда, и если пир этот - это не клиент подключённый к ноде,
а сервер, то есть нода, к которому подключен этот кошелёк как клиент,
и если порт там, на ноде - открыт во вне,
то просто заходишь туда, на ноду, по адресу: http(s)://IP:PORT/
и внезапно открывается сайт, наподобие этого,
а там команды можно вводить GET-POST-запросами,
смотреть баланс по адресу, можно блоки в JSON смотреть,
можно искать по адресу транзакции,
можно отправлять на ноду RAW-транзакции,
и броадкастить их через неё в децентрализованную сеть...
Ну ты понял...

Мог бы также открываться block-explorer, наподобие этого: https://miner-control.de/explorer/ARC
Но всё это - надо встроить внутрь самой ноды, то есть - внутрь каждого пира.

Вот если такое сделать, то можно будет туда и веб-кошельки цеплять, чтобы они работали с нодами через это API.
Просто в веб-кошельке список нод прописал, и коннектишься к ним.
Стали неактуальны? Другие адреса нод просто ввёл, и работаешь себе дальше, но уже через них.

Так, кстати, работает тот же waves-lite-client (тут исходник), а тут - онлайн версия.
Там, в исходнике, если заметишь, коннект идёт на доменное имя, wavesplatform.com, где размещено API,
но можно и на свою ноду, waves full node всё это дело подключить, прописав http://localhost:PORT/ и без проблем работать через эту ноду.

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

Что касается замусоривания блокчейна... Сейчас блокчейн биткоина занимает более 200 гигабайт.
Для Ethereum: Ну, потому что там токены всякие гоняются, и транзакции токенов - тоже в блокчейн пишутся...
А теперь представь, вкатывается новичёк. Хочет full node себе поднять. А ему надо 3 терабайта выделить. Он будет ставить ноду?
А синхронизировать её... Ну вот... Так, со временем, сеть может остаться вообще без нод.

Что касается полезности вычисления... Ну...
Я предложил вычислять протеины в проектах распределённых вычислений.
Не знаю, насколько это полезно, но можно вычислять например структуру вакцины от рака.
Критерием полезности было бы просто успешно-выполненное задание на определённый объём FLOP/MIPS,
или успешное сравнение двух результатов выполнения одного и того же задания
(ведь в процессе выполнения задания на одной машине - могут быть ошибки вычисления).
А вот сами проекты и задания - изменялись бы, в зависимости от их актуальности для человечества.
И да, кстати, есть уже https://gridcoin.us/ , но как монета - он уже всё.

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

А вот что касается трат баланса при неактивности, насколько я помню, были даже криптовалюты,
где в режиме prune сам блокчейн был бесконечен.
Так вот, там, например от 0 до 500000 блока всего. А сгенерировано 1000000 блоков.
Итого, в системе от 500000 до 1000000-го блока - все блоки есть. 500000 блоков всего последних.
Так вот, там, предыдущие блоки - они просто не учитывались, и как-бы выдавливались из стэка.
И если кто-то получил монеты на 499999-м блоке, и 500000-блоков был неактивен,
заходя в кошелёк он увидит там ноль, либо часть баланса,
так как нет определённых неизрасходованных выходов в пределах последних 500000 блоков.
Схема очень примитивная, но наглядная.
Конечно, это тупо, ведь человек может завещать PRIVKEY внукам,
и положить его лет на надцать - в ячейку швейцарского банка.
Что тогда?

У него тоже открытый исходник и тоже можно слить его в zip и форкнуть.

Там для альтов, просто префиксы и параметры задаются в html-коде index.html и всё.
Я увязал это на все другие функции, в частности на генерацию Chains для альтов, и подпись, чтобы всё это работало.
Достаточно выбрать монету в выпадающем списка.
Также, доступна работа с Ethereum.
Отдельный скрипт - для этого прилагается.
Доступна локально цифровая подпись и проверка её не только для альтов, но и для эфира,
ибо то что удалось найти мне ранее - так это некий "онлайн-сервис", вроде этого: https://etherscan.io/verifySig
А тут, всё это - локально из zip, и без Интернета, можно работать с подписями.

Работоспособность подписей я проверял через сами кошельки. Там подписывал, в скрипте проверял.
В скрипте подписывал, в кошельке - проверял.

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

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

Да я знаю, и качал его, там блокчейн уже больше 200 гигабайт весит.
Вопрос был в том, что вы именно хотели бы сделать в браузере?
Какие именно фичи из Bitcoin Core?
Вы же не собираетесь 200 гигов блокчейна хранить, в браузере, и раздавать блоки и синхронизировать их верно?
Хотя... WEBRTC есть же!
И видео-трансляции, видеочаты всякие тоже можно p2p сделать через браузер,
надо только STUN-сервера для связи пиров.

В своей PDF-ке, Сатоши Накамото - описывает сам блокчейн, и только касается ECDSA, причём косвенно во фразе из нескольких слов:
А вот здесь - параметры самой эллиптической кривой биткоина, она стандартна.

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

И мне кажется, всё это уже есть.
По-крайней мере у тех же WAVES, прямо на нодах есть встроенное API.
И вот одна из таких нод: https://waves.guarda.co/