>хотелось бы универсальный веб-кошелёк для всех криптовалют
Напиши сам.
Ты же понимаешь, что для каждой валюты нужно вручную добавлять block explorer, с которого можно брать транзакции? Понимаешь, что должен работать сервер, который будет пушить твои транзакции из веба в саму сеть?
>Напиши сам.
Я не кодер, я просто хожу вокруг да около вот и всё.
>Ты же понимаешь, что для каждой валюты нужно вручную добавлять block explorer, с которого можно брать транзакции?
И да, и нет. Дело в том, что я заметил следующее:
когда qt-кошелёк какой-либо монеты не синхронизируется,
для успешной синхронизации (загрузки блокчейна) - достаточно добавить записи addnode в файл config.conf
и запустить qt.exe с параметром -conf=config.conf
Но надо знать эти ноды. Они обычно публикуются в первом посте треда на bitcointalk.org
Если их нет - можно загуглить места, где майнят %криптанейм%
и в качестве ноды - прописать там IP(domain):port пула, где идёт майнинг монеты.
Так вот, при таком раскладе, блокчейн в qt тоже вытягивается полностью с этого пула,
а значит его можно было бы и пропарсить в веб-кошельке или даже сделать
некое подобие block explorer'a внутри самого веб-кошелька - для навигации по блокам блокчейна на ноде.
К тому же есть ещё один немаловажный момент.
Когда прописываешь одну ноду в конфиге, порой qt выдаёт 2,3,5 и более connections.
А это значит, что на ноде работает нечто вроде DHT, и сама нода содержит список этих других рабочих нод.
Таким образом, я считаю, что block explorer'ы, и ссылки на них, как таковые не нужно бы прописывать,
а следовало бы прописать хотя-бы одну рабочую ноду,
которая при подключении - слила бы DHT с IP и портами других рабочих нод, и позволила бы сохранить это всё в файл.
И так - для каждой крипты.
Более того, я знаю, что block explorer'ы обычно поддерживают поиск по номеру блока, и экспорт блока в JSON.
Например тот же Signatum: http://explorer.signatum.io/
Если ввести номер блока 1500,
а затем букву i рядом с SIGT block: 9d0ce35e0dc8fd48a2787a3cabfd4c6c88eae4afefaccc1ef5614147d0a44878
можно получить весь 1500-й блок в JSON-формате:
{
"hash": "9d0ce35e0dc8fd48a2787a3cabfd4c6c88eae4afefaccc1ef5614147d0a44878",
"confirmations": 53114,
"size": 900,
"height": 1500,
"version": 7,
"merkleroot": "7a6c9b35c62b43cd6771dda14a716d94c37b4d23f56fedd50fa4482d4db629e1",
"mint": 2500.0003,
"time": 1500438210,
"nonce": 2279592200,
"bits": "1c0522dd",
"difficulty": 49.84168387,
"blocktrust": "31d7aa6fcd",
"chaintrust": "2bb144093493",
"previousblockhash": "380c104ffe086a59163987c6c546b77331fca6b4858525a892a5f31c890cff7b",
"nextblockhash": "470fe6d71a59fb9e6b0e46d780d7025032539c219688d68c8fec969f753e2eb7",
"flags": "proof-of-work",
"proofhash": "00000000015ca3c73ef62a5a7ffde9ab5ff7ddc22e84dce8f010218b1982cefc",
"entropybit": 0,
"modifier": "33aa34a818b646fe",
"modifierv2": "8fe856f0aa3bb8cfb91ac374478e4879b0b48cacee1f554077029a4062ea6b25",
"tx": [
"ff0c37c5188766d2337b9da493780026c82efff538470434f9d21cc8d05a93b2",
"9d3e800f91bd10f583f0ff1c058c27804aa4e04a0aa9cfc95fc21cd93ad036df",
"696781ac1315022c98658a4cf41257b7124afc92feb470bac6ad882e93abba26",
"58ebfd9e13025597b88704929fe3e7acbb70b173288e5b56775ff92606654cb3"
]
}
Это значило бы, что из ноды можно было бы загружать определённые блоки, в которых содержатся только транзакции,
относящиеся к добавленным адресам.
>Понимаешь, что должен работать сервер, который будет пушить твои транзакции из веба в саму сеть?
А вот тут вот непонятно - действительно ли надо statis IP и проброшенный порт во вне,
или же можно просто заюзать рандомный socket IP:port - как в bit torrent.
Ведь чтобы отдать файл, например, через торрент, не всегда требуется сервер.
>я считаю, что block explorer'ы, и ссылки на них, как таковые не нужно бы прописывать, а следовало бы прописать хотя-бы одну рабочую ноду,
Ну вперёд, прописывай. Не забудь подумать, как будешь с веб-страницы коннектиться на рандомный порт, общаться с нодой по кастомному протоколу и получать информацию о транзакциях, не зная, в каких именно они блоках.
Ты сейчас порешь полнейшую хуйню и даже не понимаешь этого.
>Ну вперёд, прописывай.
Я не умею прописывать.
>Не забудь подумать, как будешь с веб-страницы коннектиться на рандомный порт
websocket nodejs же, не?
>общаться с нодой по кастомному протоколу и получать информацию о транзакциях, не зная, в каких именно они блоках.
Ну, в любом block explorer'e, например можно осуществлять поиск по хешу транзакции,
и такой поиск работает быстро, но только когда все блоки загружены и блокчейн синхронизирован.
А если искать в блокчейне, пула, то очевидно, что каждый блок надо загружать, смотреть в нём txhash, и если нет - выкидывать не сохраняя.
В таком случае, трафика дофига будет для поиска каждой конкретной транзакции, вплоть регулярной выгрузки всего блокчейна для одного поискового запроса.
Поэтому поиск по хешу транзакции лучше бы мутить в block-explorer'e на удалённом сервере, где загружен полный блокчейн,
или прямо на ноде, например через - API.
Кстати, если список нод обновляются по DHT, можно было бы туда и актуальный block explorer пхнуть в этот список,
или вообще встроить сам интерфейс в сеть, и сделать его полнофункциональным и децентрализированным, с доступом к нему по SSL.
Ну, например так:
1. Oтправляешь на ноду запрос GET http://explorer.signatum.download/tx/fc601dca05861b72f3dbd15b6900d4c148392180ab896f01c49057aa50c2b8aa
2. Нода, как прозрачный прокси, но по SSL - обращается к block explorer'у с этим запросом.
3. После чего, сама нода отвечает со своего IP:PORT так:
http://explorer.signatum.download/api/getrawtransaction?txid=fc601dca05861b72f3dbd15b6900d4c148392180ab896f01c49057aa50c2b8aa&decrypt=1
только не ссылкой, а кодом JSON через SSL.
Но если так, колдуя с блокчейном, переделывать какой-то конкретный альткоин,
это будет просто его фича, а не обновление стандарта у всей платформы.
А хотелось бы шустрый веб-валлет для всех монеток. И скорее всего - это уже где-то есть.
Эпичный долбоёб.
Чё за невнятный пук, сажедебил?
Я тут кстати нашёл мультикриптовалютный paperwallet, который сразу генерирует целую пачку приватных ключей и адресов,
и универсальных блок-эксплорер для разномастной крипты:
На самом деле - таких блок-эксплореров много, особенно на мультикриптовалютных пулах:
http://yiimp.ccminer.org/explorer
http://zpool.ca/explorer
http://lpool.name/explorer
http://pool.minertopia.org/explorer
и можно было бы к ним обращаться с запросами из web-кошелька,
ведь эти блок-эксплореры не просто подключены к полным блокчейнам,
но и поддерживают поиск по хешу транзакции!..
Вот ты спрашивал:
>как будешь
>получать информацию о транзакциях, не зная, в каких именно они блоках
Вот, например: http://zpool.ca/explorer/SIGT
Надо найти транзу с хешем транзакции dd7295e3b9d6fdc6f0aa1fb560e7c1ddea52b012d6059fde40ea69df1b7390d4
Вводишь его в поле поиска - прокидываешься на http://zpool.ca/explorer/SIGT?txid=dd7295e3b9d6fdc6f0aa1fb560e7c1ddea52b012d6059fde40ea69df1b7390d4
Клацаешь на хэш - получаешь транзу в JSON. Там, в коде - есть хеш блока, в который включена эта транза.
"blockhash": "578d02d227627c2967fa5424c5a5b2a9df33c755df5065e2767630598c3c11cd"
Дальше, находишь глазками этот blockhash вверху, клацаешь по нему - получаешь весь блок в JSON.
Там есть значение "height": 56205 - это твой искомый номер блока.
Дальше, можно его в таком же виде и сохранить, включая входящие в этот блок транзакции, причём - не обязательно все, а по какому-нибудь критерию.
Посоны, предлагаю рассмотреть схему оптимизации длинных и огромных блокчейнов,
при обеспечении ликвидности крипты но минимальном размере блокчейна.
Итак...
При майнинге, в блок включаются хеши транзакций.
Например, вот блок 61943 в JSON: http://explorer.signatum.download/api/getblock?hash=4164cc83059671e1f61ed17634c95d626c30386fd4976ad308a554e9e3670bdf
Неподтверждённые транзакции обычно висят в пуле неподтверждённых транзакций.
Например вот: https://blockchain.info/ru/unconfirmed-transactions
У биткоина есть пул неподтверждённых транзакций, в котором скапливается за определённое время овер 10000 транзакций где-то.
Блок выходит раз в 10 минут в среднем, и в 1 блок включается по 2000 транзакций где-то.
Когда майнеры майнят блок, они включают эти транзакции в него, и кто быстрее подберёт nonce, тот и получает награду.
Быстрота обработки транзакций требуют быстрой генерации блока и роста блокчейна.
Как, например, в Incakoin: http://www.fuzzbawls.pw/explore/IncaKoin/index.php
Быстрая генерация блоков - требует маленькой сложности и времени выхода блока.
Всё это приводит к росту блоков в цепочке блоков. У incakoin на данный момент - 2082265 блоков.
Транзакции в raw-формате - подписываются приватными ключами отправителей.
Оптимизация блокчейна требует раздвоения блокчейна т. е. по сути создания форка блокчейна с определённого блока,
и формирования транзакций от источника монет - до держателя одного или нескольких неизрасходованных выходов.
Источником монет в альткоинах, как правило являются майнеры, получающие монеты на адрес монеты,
от несуществующего системного адреса "New Coins" или "No Inputs (Newly Generated Coins)".
Так вот, для оптимизации блокчейна - можно было бы генерировать монеты
сразу на адреса владельцев неизрасходованных выходов - пропуская все промежуточные транзакции.
Но адрес получателя награды лишь один в любом блоке.
Поэтому, можно использовать для получения награды за блок - некий системный адрес,
не имеющий приватного ключа, типа адреса для сжигания монет в MarijuanaCoin:
MARxxBURNxxMARxxBURNxxMARxxxuTj3Lz BURN ADDRESS | Unspendable Funds - Not Counted In Supply
Но этот адрес должен иметь возможность отправлять монеты держателям без приватного ключа.
Поскольку все транзакции подписываются приватными ключами отправителей,
и для формирования транзакции необходимо формирование цифровой подписи этим приватным ключем,
а значит и сам приватный ключ - можно запрограммировать подпись транзакций хешем хешей всех неизрасходованных выходов получателя.
Таким образом, схема оптимизации блокчейна следующая:
1. Выбирается блок для раздвоения блокчейна - создание форка блокчейна.
2. Извлекаются все адреса, имеющие неизрасходованные выходы.
3. Извлекаются все транзакции для каждого уникального адреса, хешируются их хеши, с образованием одного хеша.
4. Этот хеш - является по сути одноразовым приватным ключём для подписи транзакции с системного адреса.
5. Формируется транзакция на адрес держателя. Формируется множество таких транзакций для всех других адресов.
6. Эти транзакции попадают в пул неподтверждённых транзакций.
7. Идёт генерация блока.
Nonce для блока представляет из себя хеш хешей подписанных транзакций, поэтому генерация блока осуществляется быстро.
Никаких комиссий. Системный адрес получает "New Coins" и сразу же отправляет их держателям в одном блоке. Никаких монет на системном адресе.
8. Дальше, старые блоки более длинной цепочки, по идее - должны отвергаться, так как прошло раздвоение блокчейна. Но это должны проверить все.
9. Дальше, сеть и майнинговые пулы проверяют каждый адрес каждого блока на наличие неизрасходованных входов, и суммируют всё это.
По сути - это сравнение circulating supply. Затем, идёт отторжение более длинной цепочки блоков после раздвоения.
Отсутствие нулей в хешах оптимизированных блоков, по-сути - несущественно, поскольку надо это для регулирования сложности и времени выхода блока.
На выходе - небольшое количество блоков непосредственно держателям монет, и намного более короткий блокчейн. Система может работать дальше.
Обновленный блокчейн может быть продолжен обычным майнингом,
и может быть оптимизирован снова не только с последнего оптимизированного блока, но и с самого начала.
Эта процедура может быть регулярной, чтобы не качать по два миллиона блоков на жёсткий диск.
Как вам такое?
>некий системный адрес, не имеющий приватного ключа,
>типа адреса для сжигания монет в MarijuanaCoin
>MARxxBURNxxMARxxBURNxxMARxxxuTj3Lz BURN ADDRESS | Unspendable Funds - Not Counted In Supply
Ссылка отклеилась: http://blockchain.marijuanacoin.net/richlist
Проблема, которую я вижу при таком обновлении блокчейна ликвидной крипты с малой сложностью майнинга - это двойная трата.
Ведь при раздвоении блокчейна, транзакции висят неподтверждёнными и продолжают отправляться пользователями.
А майнеры - продолжают майнить и генерировать новые блоки.
Если сложность небольшая и крипта ликвидная - блоки выходят быстро, транзакции подтверждаются тоже быстро.
На момент оптимизации блокчейна может быть не ухваченным новосгенерированный блок или их значительная часть.
Или может быть осуществлена трата из неизрасходованного выхода одного или множества адресов.
При этом, может быть достаточно подтверждений у этих транзакций, и тогда это уже реально двойная трата.
Одно дело если майнеры просто будут терять награду за блоки, сгенерированные после блока,
который был выбран конечным для оптимизации, так как их блоки отклоняются сетью, а на пулах статус orphan у них.
Но это не очень справедливо.
Почему может быть двойная трата?
А потому что отправитель, неизрасходованный вход которого включён в оптимизированный блокчейн,
отправляет транзу в пул неподтверждённых транзакций,
а майнеры майнят блоки быстро, если сложность маленькая, и эта транза включается в блок и подтверждается быстро.
Что тогда?
Тогда, генерация оптимизированных блоков и проверка должна идти ещё быстрее, чем генерация нового блока.
С предопределённой и жёстко заданной программно nonce,
которую не нужно подбирать вовсе - это легко реализовать.
Например, если этой nonce будет хеш всех оптимизированных транзакций,
и этот хеш не нужно перебирать, брутить, и его достаточно легко просто вычислить на основе открытых данных.
Но если время оптимизации не позволяет опередить всех майнеров,
то принятие новых транзакций в пул неподтверждённых транзакций - не должно происходить во время оптимизации.
Также, не должна происходить и генерация новых блоков.
На момент оптимизации - сложность следующего блока должна быть задрана до небес,
а майнерам и пулам - сигнал о обновлении блокчейна и необходимости проверки новых блоков.
Если майнер просто майнит - то json error get block ему в майнер,
ну чтоб видяхи и процессоры приглушились, и ток не палился зря.
А вот на пулах - проверка транзакций на соответствие неизрасходованным выходам каждого адреса,
вместо поиска nonce, или же просто упрощенная проверка
circulating supply на момент выхода предыдущего блока,
и circulating supply в системе обновленного блокчейна,
с дальнейшим обновлением его и отклонением старого -
ну чтобы не проверять сами транзы и адреса.
Но лучше проверять и более того - ещё и пропускать блокчейн через корректирующие коды,
вместо того чем искать nonce - всё для гарантии целостности нового оптимизированного
блокчейна при гипотетическом наличии программно-аппаратных ошибок вычислений
и ошибок чтения-записи, например.
Теперь, хотелось бы рассмотреть следующее...
Вот как сделать, чтобы транзакция с системного адреса - подписывалась рандомными ключами?
Обычно, адрес - это priv_key × G = pub_key, и hash ripemd160 от sha256 -> to Base58Check,
где priv_key - приватный ключ (hex 256 bit),
G - генераторная точка на эллиптической кривой,
pub_key - публичный ключ (точка на эллиптической кривой),
ripemd160 и sha256 - алгоритмы хеширования,
Base58Check - кодировка WIF-формата.
Поэтому, для подписи транзакций рандомными ключами - надо, чтобы разные priv давали один и тот же pub.
Решением могла бы быть некая "нулевая" генераторная точка на эллиптической кривой.
При умножении на priv, она давала бы один и тот же PUB.
Конечно же, с модификацией открытого ключа алгоритмом, под системный адрес, коим является его хеш в Base58Check.
А если такого открытого ключа не существует, как в адресах для сжигания, например,
тогда при умножении нулевой генераторной точки на любой приватный ключ,
по идее должнен выдаваться один единственный адрес, но не системный,
поэтому - с последующей модификацией его детерминированным алгоритмом, уже под системный адрес.
Очевидно, что при таких раскладах, любой приватный ключ сможет подписать транзакцию с такого "общего" адреса,
и чтобы такой херни не было, на этом адресе всегда должен быть - ноль.
Обычно, транзакции, включаемые в блок - содержат хеши транзакций неизрасходованных выходов отправителя,
пикрелейтед,
а поскольку транзакции в моём случае отправляются для включения в блок до генерации монет на общий адрес,
этот хеш неизвестен, и может быть стандартным, общим и иметь постоянное значение,
к которому после преобразований приходил бы любой другой хеш. Допустим, там - одни нули.
Таким образом, зная такой стандартный и общий хеш, и используя любой приватный ключ для подписи транзакции,
можно было бы сформировать и подписать в сеть транзакцию на любой свой адрес,
и отправить её в сеть для включения в блок обновляемого блокчейна.
Но прежде чем включать транзакцию в блок, система должна бы проверить адреса получателей
по всему старому и отторгаемому блокчейну, проверить там баланс каждого адреса,
затем сравнить сумму транзакции и сумму неизрасходованных выходов по адресу.
Если нет совпадения - транзакция отклоняется.
Если есть - транзакция включается в блок, а на сумму всех транзакций - начисляется награда за блок,
без комиссий отдаваемая получателям сразу же, в этом же блоке, чтобы на адресе был ноль.
По окончанию генерации блоков оптимизированного блокчейна - производится проверка общего количества монет в системе,
и расшаривание последнего сгенерированного блока по пулам и майнерам,
ну, чтобы они майнили все в дальнейшем - уже с этого конкретного блока.
Вроде всё, больше проблем не вижу... Жду конструктивной критики, аноним.
Про схему оптимизации длинных блокчейнов с сохранением ликвидности крипты
я расписал в этих трех постах: >229840
Хотелось бы услышать конструктивную критику.
А вот что касается веб-валлета для всех альткоинов, ко всему тому, что сказано выше,
добавлю ещё следующее:
При вводе priv биткоина - идёт загрузка неизрасходованных входов с blockchain.info, которые вставляются в транзакцию.
Формат - JSON по адресу вида: https://blockchain.info/unspent?cors=true&active=124fqaiRtytTmSbCMxKzqrtfXdpMvDmfDK
Эти неизрасходованные входы являются неотъемлемой частью формирующейся и подписываемой транзакции,
перед отправкой её в сеть. Отправка транзакции производится сюда: https://blockchain.info/pushtx?cors=true
после чего blockchain.info выдаёт положительный ответ или ошибку.
Никакой закачки блоков. Баланс может быть доступен после суммирования неизрасходованных блоков.
Ответ с неизрасходованными блоками в JSON-формате может быть сохранён файловой операцией,
а сохранённые данные - могут быть изменены после отправки транзакции, с последующим обновлением баланса.
Не обязательно качать блоки блокчейна, чтобы отправить транзакцию - достаточно иметь priv,
и связь с сайтом blockchain.info - через сеть Интернет.
Но....... Это только биткоин... И вообще, blockchain.info - это что-то вроде сервиса, это не сам блокчейн.
Обращение к нему похоже на обращение к сервису через API, и вся эта структура может наебнуться,
если внезапно, например, может быть конфискован домен или ещё какая-то хуйня произойдёт, нувыпонели.
Таким образом, исключить это можно было бы прямым обращением к блокчейнам на нодах,
но это, возможно, требовало бы модификаций и внедрения API на нодах - во все альткоины.
Я также вижу, что слева, на сайте https://brainwalletx.github.io/#tx,
там, в выпадающем списке, где BTC - есть множество криптовалют.
Но при избрании очередной крипты, типа FeatherCoin,
после перехода на страницу транзакций, из priv генерируется адрес,
но обращение идёт всё-равно на blockchain.info как у биткоина, поэтому и не фурычит ничего.
Отака хуйня, малята.
>При вводе priv биткоина - идёт загрузка неизрасходованных входов с blockchain.info, которые вставляются в транзакцию.
>Формат - JSON по адресу вида: https://blockchain.info/unspent?cors=true&active=124fqaiRtytTmSbCMxKzqrtfXdpMvDmfDK
>"value": 3237000
Кстати, value - это количество сатош.
На данный момент, баланс на этом рандомно-выбранном из блокчейна адресе составляет 0.03237 BTC,
что равно 0,03237000 BTC или 3237000 сатоши, при наличии лишь одного неизрасходованного выхода.
Просто скопипащу сюда JSON-ответ по этой ссылке, пока там ничего не изменилось, и юзер не перевёл бабло:
{
"unspent_outputs":[
{
"tx_hash":"9e074a74e874b7d4cecdd8c130de68e7b326af6c1db930a98f8f7281cbe98432",
"tx_hash_big_endian":"3284e9cb81728f8fa930b91d6caf26b3e768de30c1d8cdced4b774e8744a079e",
"tx_index":280100218,
"tx_output_n": 1,
"script":"76a9140ba9cb2e14b4afbe1d296e0f711b12593eff942088ac",
"value": 3237000,
"value_hex": "316488",
"confirmations":3
}
]
}
А вот здесь, неизрасходованных входов, чуточку побольше, как и сатош: https://blockchain.info/unspent?cors=true&active=3D2oetdNuZUqQHPJmcMDDHYoqkyNVsFk9r
Это адрес одного из холдеров биткоина, входящих в топ 100: https://blockchain.info/address/3D2oetdNuZUqQHPJmcMDDHYoqkyNVsFk9r
В общем, эти неизрасходованные входы можно было бы вгружать и писать на диск, без необходимости выкачивать транзакции,
и блоки, содержащие эти транзакции - для операций с балансом без загрузки блокчейна.
И лучше всего было бы делать это не через сервис типа blockchain.info, а через JSON-запросы на сам блокчейн на любой рандомной ноде.
>Хотелось бы услышать конструктивную критику.
Ты кое-что шаришь в матане, но совершенно недостаточно, чтобы адекватно обсуждать поднимаемые проблемы.
Об этом говорят, например, предложенные и упомянутые концепции:
- несуществующего системного адреса "New Coins", который на самом деле никакой не адрес.
- хеша, который является приватным ключом (будучи при этом общеизвестным и теряя свою приватность);
- адреса, который сам по себе должен уметь отправлять монеты (при том, что адрес в принципе не способен сам по себе делать ничего);
- «нулевой генераторной точки», невозможность/бессмысленность которой очевидна любому, понимающему суть EC;
- и многих других, которые мне лень разбирать по частям.
Поэтому содержание всех твоих постов за редким исключением является бредом, то есть, не может быть сопоставлено с реальностью.
>Ты кое-что шаришь в матане, но совершенно недостаточно, чтобы адекватно обсуждать поднимаемые проблемы.
А что надо ещё шарить-то?
>Об этом говорят, например, предложенные и упомянутые концепции:
>- несуществующего системного адреса "New Coins", который на самом деле никакой не адрес.
Даже если это не адрес, транзакция начисления сгенерированных монет - содержит неизрасходованный выход оттуда, с неким значением coinbase:
Например, вот: http://explorer.signatum.io/api/getrawtransaction?txid=58d900c12e990dbb9f0261ecbbc3656b544cf432e964f16b9d058c2c52ac70f4&decrypt=1
"vin": [
{
"coinbase": "0392fb0004165bab590807ff6c4c0a0000000d2f6e6f64655374726174756d2f",
"sequence": 0
}
],
>- хеша, который является приватным ключом (будучи при этом общеизвестным и теряя свою приватность);
Вообще-то да, хеш может являться приватным ключем,
как например, вот эта secret exponent на сайте https://brainwalletx.github.io/#generator
Будучи сконвертирована из hex в Base58Check здесь: https://brainwalletx.github.io/#converter
она являет собой приватный ключ в формате WIF (Wallet Import Format).
Ты говоришь приватный ключ общеизвестен, однако в предложенном мною случае - он нужен лишь
для одноразовой подписи транзакции, и сразу же теряет актуальность после этого действа.
Более того, алгоритм проверки корректности этого хеша - может и не пропустить подписанную этим хешем транзакцию на другой адрес.
Таким образом, приватность приватного ключа по-сути - здесь не имеет существенного значения.
Более того, если любой приватный ключ мог бы при конвертации в адрес - мог бы выдавать системный адрес,
после неких его преобразований, этот адрес по-сути был бы общедоступным.
Разумеется держать монеты в таком случае на нём не имеет смысла - они сразу должны расходоваться, чтоб их не спёрли.
Более того, в этом случае я предложил расходовать их до генерации монет, включая все эти транзакции в блок - заблаговременно.
>адреса, который сам по себе должен уметь отправлять монеты (при том, что адрес в принципе не способен сам по себе делать ничего);
Здесь ты немного не понял. Да, адрес сам по себе - не отправляет монеты. Надо приватный ключ.
И здесь имелось в виду то, что любой приватный ключ гипотетически мог бы соответствовать одному и тому же адресу после неких его алгоритмических преобразований.
Таким образом, транзакция отправки монет с этого адреса, подписанная ЛЮБЫМ приватным ключём, могла бы быть корректной и принятой сетью.
Почему один и тот же адрес? А потому что это единственный адрес, транзакции с которого
могли бы и не содержать вовсе корректный хеш транзакции с неизрасходованным выходом по этому адресу.
Т. е. это должен быть системный адрес.
>- «нулевой генераторной точки», невозможность/бессмысленность которой очевидна любому, понимающему суть EC;
Ну, вообще-то я исходил из того, что ноль умноженный на любое число даст всё тот же ноль.
Под множимым нулём я подразумевалась некая 0"особая нулевая генераторная точка", любое число - это рандомный приватный ключ,
ноль на выходе - одна и та же точка, являющаяся PUB, хешируемым в дальнейшем в один и тот же адрес,
который может быть преобразован алгоритмической заменой - в системный.
Вообще-то для реализации этого можно вовсе и не умножать генераторную точку,
а использовать например её координаты в качестве координат точки, являющейся открытым ключём.
Таким образом, любой приватный ключ - мог бы и зануляться в процессе подписи транзакций от этого адреса.
>- и многих других, которые мне лень разбирать по частям.
Ну лень, так лень.
>Поэтому содержание всех твоих постов за редким исключением является бредом, то есть, не может быть сопоставлено с реальностью.
Это тебе так кажется. Ладно, пойду отсюда.
Да, анон, я так подумал, а действительно, для ужатия и оптимизации длинных блокчейнов
не нужны эти изъебства с неким системным адресом, к которому подходит любой приватный ключ,
ведь можно для оптимизации блокчейна - напрямую генерировать монеты на адреса владельцев, имеющих неизрасходованные выходы.
У меня всё это раздулось лишь по причине того, что у биткоина, как правило - один единственный адрес получателя сгенерированных монет.
Его видно в блоке в самом начале.
Но я вижу, что phoenixcoin так и делает - отправляет транзу нескольким получателям:
http://explorer.phoenixcoin.org/block/b6d793783b3306c2f9302860190dd8da22f8096e6e59198229210d2a8f73bfcb
Если тебе интересно, то мой адрес там PfZc6QFwQrUEwrK3arHYFSf885J5WBpjbm: 5.41078293,
и я смайнил вместе с другими майнерами этот блок на пуле http://atlas.phoenixcoin.org:10554/static/
по гайду https://cryptocurrencytalk.com/topic/3225-p2pool-for-phoenixcoin/
Это адрес биржи, чтоб блокчейн не качать (почти полтора миллиона блоков там).
Так вот, эта транзакция - одна единственная транзакция распределения сгенерированных монет.
Их вовсе не множество.
Вот она - во всей красе: http://explorer.phoenixcoin.org/tx/24fd4efcf79138af1d4ad01c81d6dd14d082439373199ed02e552a00674f11b2
Отсюда очевидно, что неизрасходованного входа у сгенерированных монет нет - Not yet redeemed.
Как и в случае, что я предложил выше (нули в хеше).
>этот хеш неизвестен, и может быть стандартным, общим и иметь постоянное значение,
>к которому после преобразований приходил бы любой другой хеш. Допустим, там - одни нули.
Такие дела.
>я вижу, что phoenixcoin так и делает - отправляет транзу нескольким получателям
Кстати, если в таком случае, после майнинга на пуле, скачать кошелёк phoenixcoin'a и синхронизировать блокчейн,
видно входящие транзакции на вот эти неполные суммы, и помеченны они - как ДОБЫТО.
И это несмотря на то, что транзакция начисления монет - не соответствует полной награде за блок.
Обычно, транзакции имеют тип ДОБЫТО, когда майнишь какую-нибудь крипту в SOLO, и получаешь полную награду за блок,
однако при этом, монеты падают каждый раз на новый адрес, либо транзакции типа ДОБЫТО
- видно когда получаешь POS-награды на POS-монетах.
Здесь же: http://explorer.phoenixcoin.org/block/b6d793783b3306c2f9302860190dd8da22f8096e6e59198229210d2a8f73bfcb
отправителем является адрес, который видно как "Generation: 25 + 0 total fees", т. е. никакой адрес.
И по всей видимости это и является критерием изменения типа входящей транзакции.
Там, получателями являются много адресов.
Но есть и соло-майнеры, получающие полную награду за блок - там всего одна транзакция.
Например - вот: http://explorer.phoenixcoin.org/block/aebdc757b968b02395a52563094596562f4896c01cd706dd27d769f6a74e3b51
Поэтому, вполне себе можно было бы ужать блокчейн phoenixcoin'a - просто включив все эти одиночные транзакции
в одну общую транзакцию генерации монет, например в неком Genesis block'e, чтобы был в блокчейне системы - всего один блок,
с которого продолжался бы майнинг.
Тогда и синхронизация быстрее шла бы, и ликвидность крипты была бы сохранена, и монеты держателей не утеряны.
Ну и конечно же, это можно было бы делать периодически и алгоритмически, прописав оптимизацию в открытом исходнике.
Всё потому что у PhoenixCoin'a - дохулион блоков: http://explorer.phoenixcoin.org/chain/Phoenixcoin
И в основном они представляют из себя одиночные блоки, не содержащие никаких транзакций,
кроме транзакций начисления монет за блок. Качать всё это добро не очень удобно, зато переводы в крипте быстро подтверждаются.
Если кто хочет помайнить phoenixcoin - можете проследовать сюда для начала: http://whattomine.com/coins/71-pxc-neoscrypt
Их всего 60 млн. https://coinmarketcap.com/currencies/phoenixcoin/
И там кто-то долбит его с 5-ю мегахешами: http://atlas.phoenixcoin.org:10554/static/
Но он котируется только на криптопии, а там проблемы с синхронизацией.
На странице https://www.cryptopia.co.nz/CoinInfo/ 0 connections и лишь 1482979 блок.
Мои монеты на адрес биржи - не дошли, поэтому помайнил чуток на адрес в qt, и анону рекомендую.
А вообще, ИМХО, избыточность транзакций в блокчейне и длинные блокчейны - не нужны.
Важна ликвидность, быстрая синхронизация, и сохранность всех монет - поэтому,
оптимизацию блокчейнов следовало бы автоматизировать во всех альткоинах на уровне исходного кода.
>Важна ликвидность, быстрая синхронизация
Ололо, а эти - смотрите что делают: http://educoinv.org:3001/
Block: 62216, Difficulty: 11.75886455, Network (MH/s): 17.5378, algorithm: Scrypt.
Короче, блядь, по медленному алгоритму scrypt,
на котором у меня около 500 килохешей - задрали сложность до 11-ти!
И транзакции тут идут сутками, если не неделями.
Потому что невыгодно майнить и проще периодически подключать scrypt asic.
Время генерации блока у меня, при этом составляет:
>time = difficulty × 2^32 / hashrate - время нахождения блока в секундах.
>11.75886455 × 4294967296 [H] / 500000 [H/s] = 101007,88 секунд ~ 28 часов на генерацию одного блока.
Всё это, походу - заради быстрой синхронизации кошельков при небольшом количестве блоков,
но в ущерб ликвидности - потому что крипта анонсирована ещё 20-го апреля 2016-го года, и чуть более 60к блоков.
Награду за блок сделали небольшой, ну чтобы эмиссия была сдержана + премайн
однако на битталке утверждались: 2.5 minute block targets
https://bitcointalk.org/index.php?topic=1442675.0
Поэтому для ликвидности - могли бы ещё меньше сделать награду за блок
+ периодическую оптимизацию блокчейна - со снижением сложности майнинга.
Посоны, в треде ико на миллиард зелёных, ведь мультивалютного лопатника еще никто не запилил.
NiceHash Best Profit Auto-Switching Multi-Algorithm Mining - загугли эту лопату.
это кирка, а нужна лопата, словно мешок из славных былых времён, куда можно было свалить всё своё золотишкоу.
ITT - рассматриваются два основных вопроса:
1. веб-валлет, работающий без закачки блокчейна.
Для отправки транзакций - достаточно вгрузить из блокчейна неизрасходованные выходы по адресу и сформировать и их помощью транзакцию,
подписать её приватным ключём и отправить в сеть к майнерам через ближайшую ноду.
2. оптимизация длинных блокчейнов.
Для этого - достаточно задрать сложность для следующего блока,
и пропарсив адреса на наличие неизрасходованных выходов - быстро нагенерировать на эти адреса монеты
в одном или нескольких блоках - зачищая историю транзакций, и продолжив майнинг с блока, принадлежащего оптимизированному блокчейну.
Зашёл, я значит, вот сюда: http://explorer.signatum.download/richlist
выбрал Received, и рандомный адрес оттуда.
Им оказался адрес BG8wFgtcmWm68wUevn95dbhtPJDAi3D3rV
Вот страница транзакций по этому адресу, если ввести его в поисковую строку в block explorer'e:
http://explorer.signatum.download/address/BG8wFgtcmWm68wUevn95dbhtPJDAi3D3rV
Но это всё не очень хорошо парсится, поэтому я проследовал сюда:
http://explorer.signatum.download/info
Там есть Extended API с параметрами getaddress и getbalance.
Результат - более удобный для обработки, и выглядит вот так.
Баланс по адресу - getbalance: http://explorer.signatum.download/ext/getbalance/BG8wFgtcmWm68wUevn95dbhtPJDAi3D3rV
Это значение можно использовать для генерации монет при оптимизации блокчейна.
В одном блоке, в процессе оптимизации может быть множество транзакций начисления монет, как у PhoenixCoin'a.
Транзакции по адресу в JSON-формате - getaddress: http://explorer.signatum.download/ext/getaddress/BG8wFgtcmWm68wUevn95dbhtPJDAi3D3rV
А вот здесь вот, помимо хешей транзакций - видно ещё и тип транзакций: "type":"vout" и "type":"vin".
"type":"vout" - тип транзакции, в которой текущий адрес является выходом транзакции, т.е. получателем монет.
Монеты в этом случае выходят из транзакции на этот адрес.
И ниже ещё транзакции имеющие тип "type":"vin" - это тип транзакции, в которой адрес является отправителем.
Монеты в таком случае - входят в транзакцию из этого адреса.
Проверить транзакцию можно в блок эксплорере, например - зная её хеш из результата выше:
vout: http://explorer.signatum.download/tx/b3aeb79ec94b56dfa5affd28e6955f60db69178c704ed0ee9363935f7a4f334b
vin: http://explorer.signatum.download/tx/c30ceb5173815fee3f7162ebe97d4b44f15ee29b5407a929c85ed616c0625066
но сделать это можно тоже через API в JSON, указав этот хеш - в качестве txid:
vout: http://explorer.signatum.download/api/getrawtransaction?txid=b3aeb79ec94b56dfa5affd28e6955f60db69178c704ed0ee9363935f7a4f334b&decrypt=1
vin: http://explorer.signatum.download/api/getrawtransaction?txid=c30ceb5173815fee3f7162ebe97d4b44f15ee29b5407a929c85ed616c0625066&decrypt=1
Так вот, транзакции типа vin - уже потратили монеты с адреса,
в то время как в транзакциях типа vout, где адрес является получателем,
значение "value": 105.62916295
на этот адрес "addresses": ["B65rrhhpAWMos8JDymT5AD3z7Q3yRFg73U"]
может являться неизрасходованным выходом,
и может быть использовано для конструирования транзакций в web-wallet'e,
а также для проверки количества монет на адресе перед генерацией в случае оптимизации блокчейна.
Можно было бы прикрутить подобные API на все эксплореры, а ещё лучше - прямо на ноды, на которых есть блокчейн.
Чтобы подключаясь к ноде по IP:PORT можно было бы отправлять GET_запросы подобного формата, получая ответ в JSON.
В то время как обмен нодами реализовать через DHT на принципах обмена ею при синхронизации нод - как в bittorrent'e.
Как я представляю себе подключение и проверку оптимизированного блокчейна нодами?
1. Система выбирает диапазон для оптимизации и быстро генерирует оптимизированную цепочку блоков,
начисляющую монеты холдеров на их уникальные адреса.
2. В синхронизированный кошелёк ноды, содержащей длинный блокчейн, приходит первый блок оптимизированного блокчейна.
3. Этот блок содержит в себе информацию о номере стартового блока, с которого идёт оптимизация,
а также содержит номер конечного блока, поскольку оптимизируется определённый диапазон существующего блокчейна.
4. Нода, качает блоки оптимизированного блокчейна в параллельную цепочку блоков (пикрелейтед),
начиная со стартового блока, с которого шла оптимизация, но не подключает эту цепочку до проверки.
5. Конечный блок оптимизированного блокчейна в качестве значения стартового блока
содержит значение последнего блока, указанного в первом блоке оптимизированного блокчейна.
Этот блок должен быть заменён при следующей оптимизации, так как значение конечного блока в нём - не указано.
С этого блока может продолжаться майнинг в будущем.
6. Средствами консольных команд каждого wallet'a на ноде, в диапазоне оптимизации осуществляются проверки,
которые сверяют суммы генерации монет на уникальные адреса в оптимизированном блокчейне
и суммарное количество неизрасходованных выходов по каждому конкретному уникальному адресу.
Затем, в конце, осуществляется сравнение total available supply
на момент генерации последнего блока неоптимизированного блокчейна и последнего блока оптимизированного.
7. Оптимизированные блоки могут генерироваться вообще без nonce, или nonce может быть фиксирована, для более быстрой оптимизации.
В таком случае цепочка оптимизированных блоков для каждого конкретного диапазона - будет содержать одни и те же блоки,
с теми же хешами, и эта цепочка может генерироваться на любой ноде и ещё и быстро,
совпадая при этом со сгенерированными значениями на других нодах.
В идеале, на ноду вообще может прийти просто назначенный системой стартовый и конечный блок оптимизации,
после чего генерируется цепочка оптимизированных блоков, даже автономно.
8. После всех проверок, старый блокчейн отвергается, к стартовому блоку цепляется оптимизированный блокчейн,
но старый диапазон не удаляется - а упаковывается архиватором в bootstrap и доступен из p2p через bittorrent протокол, например.
Это для историков и всяких там финансовых аналитиков, кого интересуют именно движения монет - т. е. сами транзакции.
Версии неоптимизированных bootstrap сливаются на сервер block-explorer'a, и публикуются в виде ссылок на многогигабайтные файлы.
Эта инфа может быть диверсифицирована и по дата-центрам.
9. После того, как старый и неоптимизированный блокчейн, содержащий много блоков и транзакций - уже отвергнут нодой,
и принят оптимизированный блокчейн, нода раздаёт уже его и ориентируется по нему, и с последнего его блока может быть продолжен майнинг -
просто потому, что внутри блока есть значение последнего блока неоптимизированного блокчейна, равное ему.
История транзакций после всего этого сохраняется локально, в виде файла,
а переустановке и изначальной синхронизации по оптимизированному блокчейну - она не может быть выкачана
из него, так как блокчейн оптимизирован, и содержит только транзакции генерации монет.
Если кому надо получить историю транзакций - качаются неоптимизированные bootstrap, подключаются,
после чего история транзакций сохраняется локально. Такая история не более чем информация о источниках монет и их движении.
Неизрасходованные выходы из неё - не могут быть использованы для осуществления транзакций.
Алсо, можно было бы не удалять bootstrap'ы, а хранить и раздавать их с ноды.
Но тогда на сайте експлорера должны висеть не ссылки на закачку многогигабайтных архивов, а что-то вроде магнет-ссылки.
Если оптимизация осуществляется децентрализировано, по диапазонам - то для валидации сгенерированных нодами оптимизированных блокчейнов
может быть использоваться сравнение хеша целой группы оптимизированных блоков, а также соответствие хеша всех неоптимизированных,
включённого в первый блок оптимизированной цепочки блоков.
Шизик, ты никак не успокоишься?
>И что я вижу? Block Height 10398198 blocks.
>Две недели блокчейн качать на жесткий диск, чтоб одну транзакцию сделать?!!
Посоны, а поясните-ка за параметры block_nTime и block_nNonce в конфиге Litecoin'a.
Вижу много раз эти параметры вставляли в конфиг, но нигде не написано что это значит.
У кого-нибудь есть qt лайткоина, чтобы в консоли по команде help посмотреть?
Мне кажется это что-то типа данных кастомного стартового блока или Genesis-блока,
которые можно просмотреть в block-explorer'e и прописать в конфиг - дабы не качать весь блокчейн.
Если так, то работает и может работать эта фича для всех других криптовалют?
Я вот зашёл в explorer PhoenixCoin'a, выбрал рандомный блок, и вижу там:
http://explorer.phoenixcoin.org/block/e12eec96ecdd06ed8180b7fe8bf306d684af07f570461b50b1cb249c1dcdbaee
Time: 1505601201 (2017-09-16 22:33:21) (время генерации блока в UNIX формате)
и Nonce: 16045387
Height: 1498996 (номер блока)
Эти данные можно было бы указать в конфиге, но когда я сделал так, и переименовал рабочую папку -
я вижу, что qt-wallet - все-равно тянет все полтора миллиона блоков.
Но в то же время, в файле debug.log PhoenixCoin'a я вижу некоторые странные записи:
09/16/17 22:34:12 received block e12eec96ecdd06ed8180 height 1498996
09/16/17 22:34:12 ProcessBlock: ORPHAN BLOCK, prev=70dcbab7d325d2ea9fe8
09/16/17 22:34:12 received block f9ad68c5bd98ec8d1b47 height 1498991
09/16/17 22:34:12 SetBestChain: new best=f9ad68c5bd98ec8d1b47 height=1498991 work=3622093597772038 date=09/16/17 22:27:24
09/16/17 22:34:12 ProcessBlock: ACCEPTED
09/16/17 22:34:12 received block 284856559a8bc6316a59 height 1498992
09/16/17 22:34:13 SetBestChain: new best=284856559a8bc6316a59 height=1498992 work=3622099972041178 date=09/16/17 22:29:26
09/16/17 22:34:13 ProcessBlock: ACCEPTED
09/16/17 22:34:13 received block 62f311316c9326800fcd height 1498993
09/16/17 22:34:13 SetBestChain: new best=62f311316c9326800fcd height=1498993 work=3622106346310318 date=09/16/17 22:30:59
09/16/17 22:34:13 ProcessBlock: ACCEPTED
09/16/17 22:34:13 received block 2f33edd19b858e377501 height 1498994
09/16/17 22:34:13 SetBestChain: new best=2f33edd19b858e377501 height=1498994 work=3622112720579458 date=09/16/17 22:33:04
09/16/17 22:34:13 ProcessBlock: ACCEPTED
09/16/17 22:34:13 received block 70dcbab7d325d2ea9fe8 height 1498995
09/16/17 22:34:13 SetBestChain: new best=70dcbab7d325d2ea9fe8 height=1498995 work=3622119094848598 date=09/16/17 22:33:08
09/16/17 22:34:14 SetBestChain: new best=e12eec96ecdd06ed8180 height=1498996 work=3622125469117738 date=09/16/17 22:33:21
09/16/17 22:34:14 AcceptPendingSyncCheckpoint : sync-checkpoint at e12eec96ecdd06ed8180b7fe8bf306d684af07f570461b50b1cb249c1dcdbaee
09/16/17 22:34:14 ProcessBlock: ACCEPTED
Что как-бы намекает на какое-то ускорение синхронизации SetBestChain и sync-checkpoint.
Вот, допустим, я знаю, исходя из данных block-explorer'a,
что моя первая транзакция включена в блок 1498996, я мог бы вытащить оттуда хеш блока,
block_nTime и block_nNonce, и объявить его Genesis-блоком. Ну а нафига качать все блоки до этого?
Можно ли так сделать? А если нет, нахрена нужны эти параметры на пикче?
Пиздос.
Кстати, посоны!
Меня тут внезапно посетила такая идея
по поводу оптимизации длинных блокчейнов:
Генерировать монеты с хешем запакованного и сжатого блокчейна включённого в генезис блок оптимизированного блокчейна.
Поскольку в каждый блок включаются хеши транзакций, как на первой пикче ОП-поста,
и поскольку это может быть хеш любой информации,
можно же взять длинный блокчейн,
запаковать его в bootstrap.dat,
просчитать хеш этого файла файл,
и включить этот хеш в первый блок оптимизированного блокчейна,
причём вместе с транзакциями начисления монет и токенов всяких, если речь идёт о блокчейне эфира например.
У эфира, я вижу на данный момент Server Block: 4416692, т. е. около 5-ти миллионов блоков.
Качать всё это дело и хранить на диске не очень хочется, поскольку там чужие и давно не актуальные транзакции.
Так как важны балансы самого эфира и различных токенов,
всё это можно было бы нагенерировать вот таким вот образом:
http://explorer.phoenixcoin.org/block/b6d793783b3306c2f9302860190dd8da22f8096e6e59198229210d2a8f73bfcb
при оптимизации блокчейна, но не только сам эфир, но и токены различные,
а чтобы убедиться в том, что всё правильно - в блок в котором идёт генерация монет и токенов,
можно было бы включить хеш блокчейна.
Таким образом, все монеты и все токены на всех адресах,
на которых они есть в виде неизрасходованных выходов в момент оптимизации блокчейна,
могли бы быть нагенерированны, а транзакции их генерации могли бы поместиться если не в один, то в несколько блоков,
что существенно ускорило бы синхронизацию и как следтвие - ликвидность любой монеты.
А bootstrap.dat со старым блокчейном - для историков и финансовых аналитиков всяких,
ну и расшарить его можно для закачки через торрент.
>Здесь https://brainwalletx.github.io/#tx есть возможность сформировать
>и подписать исходящую транзакцию приватным ключем, и даже отправить в сеть,
>но эта функция не работает почему-то, возможно blockchain.info изменил что-либо.
Вижу приватные ключи и адреса у альткоинов отличаются префиксами публичного ключа,
префиксом приватного ключа, а также, адреса могут быть либо сжаты, либо несжаты.
Подправил исходник брайн-валлета, добавив туда XOR - а то нашёл тут вот что:
https://rya.nc/cracking_cryptocurrency_brainwallets.pdf https://bitcointalk.org/index.php?topic=1148611.0
В общем, зацените: http://rgho.st/8hlwbSy98
1. Unzip в папку.
2. index.html -> на вкладку браузера.
Возможно, теперь можно будет локально подписывать RAW-транзакции
и отправить их в сети монет майнерам и майнинговым пулам,
как через waves web-wallet.
Это открывает путь к созданию «мультиальткоинового веб-кошелька»,
для переводов и массовых платежей - без необходимости загрузки каких-либо блоков блокчейна.
Может чё ещё подправить надо? А?
Решил добавить пару функций ещё после того, как сходил на сайт биткоин-голда http://btcgpu.com/
Там я увидел форму, в которой можно ввести биткоин адрес и просмотреть баланс форка.
Там я увидел ссылку на сайт https://MYBTGWALLET.COM и сразу вспомнил по созвучию, что MyEtherWallet - это веб-валлет.
Поэтому я прошёл туда и увидел нечто типа недопиленного то-ли генератора, то ли веб-валлета.
Адреса там начинаются с символов G и A. Сжатые и несжатые.
Я скачал zip этого творения и увидел в исходнике байты public key version 0x27 (G) и 0x17 (A) для нового формата SegWit адресов.
Захотелось мне добавить оба формата адресов голда в этот предыдущий брайнваллет
Я не знаю какие адреса используются в голде - сжатые и несжатые, но оба формата ключей и адресов - тоже доступны там.
Также, я добавил поддержку новых Segwit адресов в виде кнопки и простой JS file encryptor, который шифрует файлы прямо в браузере.
Вы можете скачать новый брайнваллет здесь: http://rgho.st/7vlks4Rgh
Просто нажмите "Скачать" чтоб получить zip,
Затем разархивируйте это,
и откройте index.html во вкладке браузера.
Чтобы сгенерировать адрес для майнинга голда - выберите его в выпадающем списке.
Просто оставлю это здесь
_________________________________________________________________________________
>Задавай свои вопросы, пока я добрый, я тебе и про NAT по-хардкору могу пояснить.
Кстати, аноним, я так ещё подумал тут...
Вот ты говоришь, кошелёк может пушить смайненные блоки и транзакции в сеть через активные соединения.
Это соединения TCP. Они открываются при подключении к нодам и пирам из файла peers.dat
Так вот, транзакции, насколько я знаю, представляют из себя подписанные приватным ключём RAW-транзакции.
И они отправляются в сеть по протоколу tcp/ip через активное соединение в виде TCP-пакетов на TCP-сокет, так?
Я вижу здесь: https://brainwalletx.github.io/#tx
Если ввести какой-нибудь приватный ключ от пустого адреса 5KYZdUEo39z3FPrtuX2QbbwGnNP5zTd7yyr2SC1j299sBCnWjss
и адрес получателя (пусть это будет тот же адрес): 1HZwkjkeaoZfTSaJxDw6aKkxp45agDiEzN
то можно увидеть JSON транзакцию, и Raw Transaction, представляющую из себя хеш.
Поскольку RAW-транзакции отправляются в сеть, будучи подписанными,
то подписать сообщение можно на вкладке https://brainwalletx.github.io/#sign
введя этот же, например, приватный ключ.
Там генерируется цифровая подпись, но помимо её ещё добавляются некие заголовки.
Я думаю не было бы бы проблемой обрезать всё это в исходном коде JS,
и получить подписанную RAW-транзакцию в поле на вкладке https://brainwalletx.github.io/#tx
Дальше, поскольку подписанные raw-транзакции отправляются в сеть в виде TCP-пакетов на сокеты тех же доступных их сети нод,
я думаю не было бы проблемой перекодировать их в виде TCP-пакетов, и запушить на ноды через какой-нибудь
var mySocket = new TCPSocket("127.0.0.1", 6789);
WebSocket или raw-sockets на JS - прямо из браузера:
https://stackoverflow.com/questions/12407778/connecting-to-tcp-socket-from-browser-using-javascript
Возможно для этого, в какое-нибудь дополнительное поле, следовало бы ввести и список доступных нод,
чтобы спарсить его скриптом и установить с ними соединения через эти сокеты.
Ну и конечно же, через эти сокеты, я думаю с нод можно было бы выкачивать и другую инфу,
например неизрасходованные выходы под адресу, или историю транзакций,
декодируя затем эту инфу из TCP - в какой-нибудь читабельный JSON.
_________________________________________________________________________________
В MyEtherWallet можно отправлять транзы, но куда они идут непонятно.
По всей видимости, они идут на https://api.etherscan.io/api т. е. на блок-эксплорер - через какое-то API.
А надо чтоб они именно к майнерам шли и на пулы - через ноды, например.
_________________________________________________________________________________
Вот здесь нашёл нечто подобное: https://coinb.in/#newTransaction
Тут загружается история и формируется транзакция.
А вот здесь уже её можно отправить https://coinb.in/#broadcast "Broadcast"
Всё это добро можно скачать в zip отсюда: https://github.com/OutCast3k/coinbin/
там и генератор ключей с адресами есть,
но я чё-т стремаюсь вводить свой прив пока не проверю исходник.
Т. е. не буду даже вводить свой прив локально, в zip, пока не проверю все функции в исходном коде JS,
инициализируемые нажатием кнопок.
Всё потому, что здесь, у пользователя - увели биткоин через сайт недопиленного кстати веб-кошелька Bitcoin Gold:
https://bitcointalk.org/index.php?topic=2284289.msg24653522#msg24653522
Этот веб-кошелёк делистнули с оффсайта голда, и там так и писалось, что разраб веб-кошелька работает лишь на голом энтузиазме.
Короче, на этом много скама может быть замешано, с перехватом ключей, и прочей поебнёй,
но возможность написания универсального веб-валлета, при помощи функций из исходников - всё-же есть.
__________________________________________________________________________________
Можно отнести coinbin программистам в JS-треды, ну чтоб выдрали функции и прикрутили их к брайнваллету.
А то брайнваллет я перепилил кое-как вроде норм и сжатые и несжатые ключи, но он транзакции он ещё не поддерживает и не броадкастит их.
Может быть тогда и увидим универсальный веб-валлет для всех альткоинов, ну чтоб блокчейны ради одной транзы не качать, блядь.
>запушить на ноды через какой-нибудь
>var mySocket = new TCPSocket("127.0.0.1", 6789);
>WebSocket или raw-sockets на JS - прямо из браузера:
Уймись, браузеры так не умеют.
Ну есть же какие-то HTTP->tcp прокси на том же JS?
На крайняк - прогу ещё поставить вроде того же zcash-proxy,
на который можно майнить майнерами с методом get_work обращаясь к нему по HTTP,
а тот с свою очередь посылает обменивается с кошельком данными по tcp,
используя метод getblocktemplate.
Поскольку альткоины отличаются префиксными байтами приватного ключа, а их адреса - префиксными байтами публичного ключа,
и тем сжатый ли адрес или несжатый, то из всего этого, в перспективе,
вырисовывается универсальный веб-валлет для всех альткоинов,
причём портабельный, локальный, полностью на JS, и отправляющий транзы в сеть - без всяких блокчейнов и синхронизаций.
Пикрелейтед - процесс подписи и отправки подписанной RAW-транзакции через консоль кошелька bitcoin.
Я кодер с руками из жопы, который в вузе толко айти учил, а потом забил хуй. Но вижу так, что нужно что-то типа конструктура, в котором базово будут реализованы общие основные функции, а модулями можно встраивать различные альткоины с конкретными спецификациями. Тогда можно спихнуть разработку под конкретные монеты на плечи их представителей, которые будут эти модули запиливать в публичную библиотеку.
А будет ли это веб-кошель или десктопный тонкий клиент похуй.
А будет ли это веб-кошель или десктопный тонкий клиент похуй.
>нужно что-то типа конструктура, в котором базово будут реализованы общие основные функции
Есть же уже в брайнваллете там файл bitcoinjs-min.js -
в нём все функции для работы с эллиптической кривой биткоина.
Она одна для всех альткоинов.
Скачай же да посмотри исходники и затести у себя заодно как оно всё это работает.
>а модулями можно встраивать различные альткоины с конкретными спецификациями.
Прикол в том, что сами спецификации альткоинов прописываются файле index.html
одной строкой в коде списка:
<li><a data-target="compressed, 0x21, 0x80" href="https://emercoin.mintr.org/chain"><span class="pull-right">EMC</span>EmerCoin</a></li>
где compressed - значит сжатый приватный ключ и адрес,
0x21 - префиксный байт публичного ключа,
0x80 - префиксный байт приватного ключа,
https://emercoin.mintr.org/chain ссылка на блок-эксплорер.
Всё остальное дальше - работает корректно, если выбрать из списка EmerCoin.
Скачай zip, разархивируй его, и открой файл index.html в браузере. Потом выбери EmerCoin.
Но вот незадача... Транзакции - не работают, блядь.
Для транзакций в сети биткоин - используется API на сайте https://blockchain.info
Кстати, API используется и для броадкастинга транзакций в MyEtherWallet.
И даже в исходном коде coinbin - тоже можно увидеть API:
файл coin.js
строка coinjs.host = ('https:'==document.location.protocol?'https://':'http://')+'coinb.in/api/';
Поэтому, для осуществления транзакций через brainwallet разработчики каждой конкретной монеты должны пилить апи,
или должен быть сервер с API, куда подключались бы эти монеты.
Но это централизирует веб-кошелёк, и если упадёт сервер, где хостится API транзу не отправить - прийдётся качать блокчейн.
Очевидно, что так как альткоины однотипны, то их сети могут принимать транзакции на ноды в виде TCP-пакетов,
и так как транзакции отправляются подписанные, очевиднейшим образом их нужно подписать приватным ключём,
декодировать в tcp инфу, а потом уже и отправить. Таким образом, никаких API можно было бы и не пилить,
и для трансфера альткоинов достаточно было бы указать список addnode и запушить на них транзы (возможно даже массовых платежей)
через какой-нибудь стандартный и встроенный йоба-tcp-модуль.
>Для транзакций в сети биткоин - используется API на сайте https://blockchain.info
Используется в этом brainwalletx, я имел в виду.
Вот список функций API внутри биткоин клиента: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list
Многие из них выдают ответ в виде JSON, например консольная команда getblock,
но запросы идут на сам синхронизированный кошелёк, а не на ноды или даже возможно и на ноды,
если кошелёк не синхронизирован, например та же команда getblockcount - срабатывает, когда идёт синхронизация и она не завершена.
Если запросы идут прямо на ноды, то наверняка они идут через активные tcp-соединения,
в виде пакетов запрашивающих инфу, а ноды уже отвечают в виде других TCP-пакетов,
которые Bitcoin_client декодирует в JSON и выводит в виде результата в консоли.
Если так, то я думаю не было бы проблемой запилить весь API calls list в виде функций на JavaScript'e,
но для взаимодействия brainwallet'a с нодами, очевиднейшим образом надо устанановить
с ними активные TCP-соединения причём прямо через браузер, блядь.
Тогда, вполне возможно, в веб-кошельке сработала бы и функция getbalance например,
а возможно даже и getwork и getblocktemplate, ну чтобы майнить в соло - прямо на сеть,
а не на пулы, причём без какой-либо необходимости в синхронизации блокчейна длиннющего.
waves_lite_client же работает как-то прямо с нодами через Интернет.
Вот тут https://github.com/wavesplatform/WavesGUI/releases можешь скачать его,
разархивировать, и открыть в браузере index.html и затестить.
Но я не смотрел особо код, вполне возможно что там тоже вместо прямого подключения к нодам - используется API.
>В общем, зацените: http://rgho.st/8hlwbSy98
Просто оставлю это здесь: https://brain.611.to/
Но этот с голдом и сегвит адресами:
>Вы можете скачать новый брайнваллет здесь: http://rgho.st/7vlks4Rgh
Лучше скачать его в зипе, пока не удалили - заодно и ксорить можно будет на кастомные значения.
После того, как я прочитал это: https://runkit.com/gojomo/baddr2taddr/1.0.1
Я сделал дополнительные изменения:
Теперь в этом брайнваллет поддерживается t-адреса ZCash (transparent address) с байтами [0x1c, 0xb8]. Что-то типа сегвит-адресов.
- Итак, работет генерация ZCash-адреса (пожмакайте кнопку возле адреса на вкладке генератор).
- Добавил небольшой конвертер на вкладке Converter, внизу.
Там возможно преобразование адреса биткойна в t-адрес и t-address -назад в биткойн-адрес.
Переменные могут быть переданы при помощи get-параметров из url, как в PHP, но локально на компе.
- добавил ещё валидацию адресов - там просто идёт проверка контрольной суммы Base58Check.
Скачать этот BrainwalletX - можно здесь: http://rgho.st/6X8pSxsvF
1. Нажмите кнопку «Скачать»;
2. Разархивируйте zip-файл;
3. Посмотрите исходный код, файл change.txt и откройте index.html на вкладке своего браузера.
Это может работать локально и не требует соединений.
Теперь вы можете локально преобразовывать t-адрес в адрес биткойна и адрес биткойна на этот транспарент адрес, а также генерировать их.
Также, вы можете проверить корректность адресов здесь (вместо адреса запхните свой):
https://baddr2taddr-jkvbqrxovmbu.runkit.sh/1NFEViMdeYT4CcH5XLzPzsjwBiNPq8uRpg
t1f7qW3mmcsEeoFKyTmoX8gqrSNZUaDv6c6
и здесь:
https://baddr2taddr-jkvbqrxovmbu.runkit.sh/t1f7qW3mmcsEeoFKyTmoX8gqrSNZUaDv6c6
1NFEViMdeYT4CcH5XLzPzsjwBiNPq8uRpg
Адреса корректны, проверил в консоли VoteCoin.
Есть хуева туча монет, использующих t-адреса - это к примеру BTCZ, VoteCoin, ZCash,
и наверняка множетво других на базе протокола ZeroCoin. Так что вот. Enjoy!
>мультикриптовалютный paperwallet, который сразу генерирует целую пачку приватных ключей и адресов
Вот он: https://multiexplorer.com/paper_wallet/
Только здесь надо птички отмечать и генерировать. На выходе - приватные ключи и адреса для выбранных криптовалют.
Всё это - огромным списком.
Но задать приватный ключ пассфразой - нельзя.
Однако наверняка можно было бы слить этот сайт в zip или загрузить его скрипты, поколупатся в функциях,
и каким-то образом замкнуть генерацию priv на пассфразу.
Если его сохранить, он работает локально без подключения к Интернету.
Генерация адресов идёт на JS.
Я залез в исходный код, вырезал все ссылки где есть http и всё-равно работает. Значит инфа никуда не передаётся.
Я вижу внутри, где var crypto_data = [
массив с данными различных альткоинов - это префиксные байты адреса и приватного ключа.
Они идут массивом, и парсятся потом.
В общем, можно перепилить это дело и птички эти более компактно уложить в таблицу чекбоксов,
а не в один столбик...
>вырезал все ссылки где есть http и всё-равно работает. Значит инфа никуда не передаётся
>Значит
Не значит. Проверяй в веб-инспекторе.
Не знаю о каком веб-инспекторе речь, но я нажал F12, и перешёл на вкладку sources.
Там увидел одно соединение с www.google-analytics.com
после этого, удалил файл analytics.js из папки, которая сохранилась при сохранении страницы,
а также удалил скрипт, содержащий слово analytics и строку "//www.google-analytics.com/analytics.js" в исходном коде страницы.
Короче, после того как вычистил этот google analytics, никаких удалённых соединений, кроме локальных исходников не вижу.
К чему он вообще туда вшит был - тоже не читал код, лень. Потому что генерация кошельков работает и без него.
Я, тут вот что нашёл - портативный сканер портов, в виде одной страницы, которую можно сохранить: http://www.andlabs.org/tools/jsrecon.html
Она работает локально, и использует WebSockets в браузере Chrome, FireFox и Safari.
Также, кроме WebSockets - используется кросс-доменные запросы XHR (XMLHttpRequest).
В общем, можно проверить порт через браузер - даже у компа в локальной сети,
просто открыв страницу со скриптом - во вкладке браузера.
Итак, что я там вижу?
Я вижу порой, в консоли - вот такую ошибку:
WebSocket connection to 'ws://192.168.0.107:33333/' failed: Connection closed before receiving a handshake response
Я повесил свой кошелёк сигнатума на 33333-й порт и запустил его с параметром -server.
В отличие от кошелька SixEleven - параметр upnp=1 в конфиге не работает там,
поэтому чтобы сделать доступную ноду - я открыл порт, и сейчас у меня на ноде - висит несколько клиентов.
Их видно в консоли - через getpeerinfo.
Этот порт-сканнер показывает, что порт открыт, но дело не в этом.
Меня привлекло слово в консольной ошибке:
>handshake
и насколько я знаю оно переводится как "рукопожатие".
Я читал недавно про TCP 3-Way Handshake (SYN,SYN-ACK,ACK),
и если правильно понимаю, то браузер через WebSocket может удерживать keep-alive -соединение по TCP...
Например, как-то вот так:
chrome.sockets.tcp.setKeepAlive(integer socketId, boolean enable, integer delay, function callback).
Если так, то можно было бы сделать веб-валлет для хрома, который общался бы прямо с нодами.
Я хотел бы сделать из этого jsrecon, ссылка на который - выше, порт-сканер для списка addnode.
Но ума не приложу как... Там какая-то хуйня с логированием и выводом результатов...
Для чего? Ну, чтобы когда вводишь getpeerinfo в консоль,
получаешь JSON-ответ, и видишь, что в основном к тебе подключены пиры с рандомными портами,
чтобы можно было закопировать JSON-ответ,
засунуть его вот сюда:
и получить список addnode с дефолтным портом, а также портом пира.
Но поскольку не у всех пиров открыт дефолтный порт - его надо бы проверить порт-сканнером.
На ум приходит только одно, запхнуть список addnode в texarea, отправить её, а потом спарсить оттуда IP-адреса и порты,
и последовательно вызвать функцию в порт-сканнере, для проверки указанного и дефолтного порта у этих рандомных IP
(но там ещё могут быть ноды с доменными именами, ноды TOR'a и ipv6-ноды).
На выходе же - получить список только доступных нод, в формате, удобном для копирования в конфиг...
Но, как уже сказал выше, там какая-то хуйня с логом, и просрав чуть более чем два дня мне уже настопиздело её хуевертить там...
Когда последовательно вызываешь функцию проверки, лог выводится только по последнему вызову.
Т. е. как я понял, надо менять IP в функциях где он инкрементируется...
Я не могу подключиться к сети signatum ни по одной из нод в моём списке addnode. Peer Exchange - не работает там, блядь.
Поэтому я и сделал ноду, но даже с пиров, которые ко мне цепляются я не могу вытянуть список других пиров. (т. е. использовать их как seednode)
Таким образом, блокчейн рассылаются им, и только им, как и транзакции, и то пока они удерживают соединение,
что для меня, холдера - как-бы бесполезно, особенно если нет гарантии того, что эти пиры подключены к другим нодам, лол.
Ибо может внезапно объвиться некая супернода-мастернода, которая отвергнет больше половины блоков нашей локально структурированной микро-шоблы.
>засунуть его вот сюда:
ссылку забыл: https://42k5tcpg7bhjjaze.onion.to/getpeerinfo_to_addnode/ip-list_to_addnode-list.html
Эта страница тоже портативная, можно её сохранить из браузера и юзать.
Просто оставлю здесь генератор списка "addnode=" из различных списков, содержащих IP или IP:PORT,
например - на входе может быть JSON-ответ консольной команды getpeerinfo
при наличие активных соединений в кошельке).
Это генератор нод со встроенной проверкой портов у нод, в получившемся списке - прямо через браузер.
Проверка осуществляется как дефолтного порта у нод так и порта у пира (ведь пир может быть доступной нодой но с другим открытым портом).
Подробности проверки портов - в консоли браузера (обычно это клавиша F12).
Страница портативная, на JS, и её можно сохранить - вот она:
https://42k5tcpg7bhjjaze.onion.to/getpeerinfo_to_addnode/available_nodes_from_text/addnode_generator_and_port_checker.html
Для проверки портов - использовался исходный код вот этого порт-сканнера: https://defuse.ca/in-browser-port-scanning.htm
который проверяет IP:PORT GET-запросом тестовой картинки оттуда с любым содержанием.
Хотелось бы наверное ещё прикрутить туда другие методы проверки портов отсюда: http://www.andlabs.org/tools/jsrecon.html
Например при помощи WebSockets или XHR, но мне тупо впадло и не знаю как правильно это сделать, блядь...
Шизик, всё ещё пытаешься заставить браузер коннектиться по голому TCP/IP? Может, примешь уже тот факт, что этой возможности у браузеров никогда не будет по причинам безопасности?
Почему же по голому? На него можно носочки одеть (socks) или что-то типа гондона (websockets на нодах).
Аноны, только что, по телеку, у меня показали следующее:
http://провэд.рф/society/social-organizations/45198-vladelytsy-zolotoy-zemli-v-tsentpe-postova-na-donu-mogut-poluchity-za-nee-kopeyki.html
Решение о порядке выдачи компенсаций на жилье и землю пострадавшим в массовом пожаре 21 августа затягивается, люди находятся в информационном вакууме.
Здесь у людей, которые запросили немалые деньги за землю - тупо сгорели дома,
что возможно является хорошим, если не наилучшим методом
для различных посягателей на эту землю - например чтобы изгнать их оттуда,
а потом, через время - возвести на этой земле всякие новостройки.
Так вот, аноны, насколько я знаю, право собственности на землю закрепляется обычно документально, на бумагах... Там короче сидит мент и фиксирует это всё.
А изменить документы различные, всякие тем же подкупом мента или силовым давлением на всяких шишек, сидящих в кабинетах - дело нехитрое, блядь.
Вопрос следующий: возможно ли закрепление незыблемого права собственности на какие-либо вещи, землю или недвижимость,
посредством криптографических манипуляций с системами электронного документооборота,
например с использованием цифровых подписей?
Могут ли существовать такие системы на блокчейне?
Допустим, хеш координат земли - представляющий из себя уникальную цифровую последовательность,
подписывается приватным ключём некоего ThingCoin'a,
с возможностью последующей проверки по блокчейну инфы о том, что эта вещь принадлежит владельцу с определённым адресом ThingCoin'a,
и что этот владелец - реально является владельцем адреса, подписав например сообщение.
Дело в том, что сообщение обычно подписывается приватным ключём, а адрес - соответствует приватному ключу...
Это значит, что если есть приватный ключ и если подпись совпадает, выдавая адрес отправителя,
то именно владелец приватного ключа от адреса, и владелец самого адреса - подписал это сообщение.
Дальше, после проверки цифровой подписи, сеть может ассоциировать этот объект с этим адресом -
по хешу объекта например, найдя объект - через DHT в сети подобной торренту,
и помечая затем этот объект - как собственность владельца
с последующей диверсификацией инфы по децентрализированной сети, и укомплектацией этой инфы - в блокчейн.
После этого, любой юзер - может проверить, что этот объект принадлежит владельцу с определённым адресом.
Затем, владелец - может отправить объект или все объекты - кому угодно, но имея при этом - приватный ключ.
Кстати, я видел в SixEleven, NameCoin и EmerCoin - возможность transfer'a доменного имени на другой адрес,
связанный с доменным именем (адрес другого владельца, например).
Чтобы владелец внезапно не потерял приватный ключ, представляющий из себя доступ к адресу,
и контроль над собственностью привязанной к этому конкретному адресу,
приватный ключ может быть привязан к уникальным паспортным данным владельца собственности,
но так как эти данные возможно тупо похитить, перехватить, или выпытать,
используя затем - для передачи собственности другому владельцу,
то может быть применён, например, алгоритм деривации приватного ключа -
и он может быть рандомизирован с использованием совокупных флопсов децентрализированной вычислительной сети,
с регулярными трансферами при этом объектов собственности, со старого адреса - на новый сгенерированный адрес.
Понятное дело, что если объектов много, и если трансферов много,
и если каждый трансфер представляет из себя транзакцию объекта с одного адреса на другой
(ну передача прав собственности другому владельцу, или же отправка её самому себе но на другой свой адрес, при изменении приватного ключа алгоритмом деривации),
то сама деривация приватного ключа и рандомизация алгоритма деривации
порождала бы много транзакций попадающих в блокчейн,
а значит и много блоков нужно было бы сгенерировать для работы такой сети.
Много блоков и стремительный рост блокчейна при этом - наводит на мысль о необходимости регулярной алгоритмической оптимизации блокчейна (речь о которой выше),
с включением в блоки только неизрасходованных выходов, и выкидыванием из оптимизированных блоков
всех других транзакций и адресов, которым не пренадлежит ни один объект.
Дальше, при осуществлении трансфера на другой чужой адрес, могли бы использоваться хеши сигналов,
нейросетевой обработки физиологических параметров организма, подтверждающих полное согласие владельца совершить заключённую сделку.
Эта информация будучи обобщённой, с последующей фиксацией - могла бы быть включена в транзакцию передачи собственности другому владельцу,
а хеш её мог бы ещё больше рандомизировать приватный ключ нового адреса, с которого отправляется собственность - другому владельцу.
Вся инфа - публична, прозрачна, видна внутри транзакции и ищется по хешам через DHT вплоть до физиологических параметров из сенсоров.
Как вам такое? Лол.
Нет, так дело не пойдёт - там малварь Unsafe.AI_Score_98% :
https://www.virustotal.com/#/file/d819d0f9cda57e5c2a2376b628e29286c6ff6e8ffc6aa4a8ba8a97d3f39d2830/detection
А здесь, по ссылкам - голый JS в браузере с открытым исходником.
Хотя постой, я вижу он, этот ArcBit Bitcoin Wallet - есть и в виде расширения
https://chrome.google.com/webstore/detail/arcbit-bitcoin-wallet/dkceiphcnbfahjbomhpdgjmphnpgogfk
И в хроме работает нормально. Здесь он в виде портабельного exe-шника, походу.
Но здесь нельзя задать свою монету по префиксным байтам приватного и публичного ключа, а также адреса,
и нельзя добавить её, введя список addnode, чтобы удерживать с ними активные соединения, как у вавесов, например
или же подключиться к блок-эксплореру для проверки баланса и отправки транзакций через какое-нибудь API
и без необходимости качать блокчейн и синхронизировать его.
Поэтому, до универсального веб-валлета для всех альткоинов - ему далеко,
и чтобы добавить какой-нибудь TajCoin или Educoin, зная его префиксные байты -
нужно походу - рекомпилить его, и переписывать всё, в том числе исходник внутри расширения...
И да, кстати, запустил в защищённом режиме его, но вот этот exe-шник через virustotal.com - не проверял.
Что это, и почему аж туда записывается?
Накину сюда пару ключевых слов для поиска - документооборот на блокчейне, DocSensus, интернет вещей.
Было бы ещё более прикольно, если бы в интернете вещей - вещь сама выбирала
подходящего для неё владельца и просилась к нему,
с просьбой к прежнему владельцу - подписать сообщение приватным ключём,
и передать право собственности на эту вещь другому владельцу,
лишь потому что что эта вещь на данный момент - более нужная ему, а не этому.
И всё - автоматизировано короче, и на принципах ИИ работает - и всем подзаебись, даже самой вещи.
который работал бы локально, и в котором можно было бы
формировать, подписывать и отправлять в сеть транзакции,
подключаясь к блокчейну на сервере или block explorer'у через API,
обновляя и сохраняя баланс.
На пик1 - процесс включения транзакций в блоки.
На пик2 - подписанная raw-транзакция.
Здесь: https://blockchain.info/ru/unconfirmed-transactions список неподтверждённых транзакций.
Эти транзакции не включены ни в один блок из смайненных на данный момент.
Я так полагаю, они висят в пуле неподтверждённых транзаций,
являющемся общедоступном для всех майнеров и майнинговых пулов.
Здесь https://brainwalletx.github.io/#tx есть возможность сформировать
и подписать исходящую транзакцию приватным ключем, и даже отправить в сеть,
но эта функция не работает почему-то, возможно blockchain.info изменил что-либо.
Я знаю, что для отправки монет, достаточно иметь приватный ключ.
Ведь транзакция подписывается этим приватным ключем. Пик3.
А вот для проверки баланса - не обязательно иметь приватный ключ,
ведь можно зайти на block explorer, и ввести в поисковую строку просто адрес.
Также, для проверки баланса достаточно было бы отправить запрос с адресом на блокчейн,
хранящийся на удалённом сервере. И не обязательно его качать.
Ведь в block explorer'ax, если ввести адрес, поиск идёт быстро.
Я знаю, что в качестве нод, в конфигурационном файле qt-программы -
можно задать значение addnode
в виде ip адресов, доменов и портов майнинговых пулов.
Просто потому, что у них блокчейны полные и всегда последний блок имеется.
Можно ли их парсить, не выкачивая и не сохраняя?
Дальше... Это - только биткоин.
А хотелось бы универсальный веб-кошелёк для всех криптовалют.
Как у https://waveswallet.io и https://www.omniwallet.org
Ну, чтобы, можно было например:
1. Cохранить его в zip.
2. Ввести туда пароль, выбрать крипту и ввести приватный ключ потом.
3. Получить из приватного ключа адрес, и сохранить какой-нибудь файловой операцией на жестком диске.
4. Прописать ноды или адрес block-explorer'a.
5. Вытянуть блокчейн из нод, но не сохранять его, а пропарсить, и сохранить только блоки, с транзакциями на адрес
и с адреса.
6. Если используется блок-эксплорер, то вытянуть блоки в json'формате и сохранить.
7. Обновить и сохранить баланс.
8. Создать и подписать транзакцию с поддержкой множества входов и множества выходов.
9. Отправить подписанную транзакцию в сеть, например запросом к нодам.
10. Сохранить всё это в отдельном файле и зашифровать паролем.
Это всё, чтобы легко и просто оперировать монетами, без закачки блокчейна.
Вот смотрите, присмотрелся я, например к FastCoin.
Вижу монет всего в системе 165,888,000 coins, сложность небольшя, хешрейт небольшой.
Нашёл у них paperwallet, сгенерировал priv, получил из него адрес,
ввёл адрес на пул, и решил помайнить. Майнинг идёт, монеты капают, баланс в block-explorer видно.
И вдруг, туземун! И мне тут срочно приспичило слить на биржу эти жалкие 100 FAST аж за 1 BTC, например.
И что я вижу? Block Height 10398198 blocks.
Две недели блокчейн качать на жесткий диск, чтоб одну транзакцию сделать?!!
Чом бы всем хором, не запилить веб-кошелёк для альткоинов и не залить его на github?