Этого треда уже нет.
Это копия, сохраненная 1 марта 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 1 марта 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
79 Кб, 1336x742Приветствую, криптаны!
Я вам принёс мультикриптовалютный паперваллет для различных альткоинов.
Вот он: https://username1565.github.io/MultiCoin-paperwallet/
Исходник - тут: https://github.com/username1565/MultiCoin-paperwallet/
Здесь, вы можете генерировать приватные ключи в WIF-формате,
в том числе и сжатые, для различных криптовалют (bitcoin-based altcoins).
Список настроек для различных альтов лежит в файле ./index_files/COINS_ARRAY.js
Только client-side вычисления. Никаких серверов, никой отправки данных куда-либо.
Даже если через сайт открываете, то сначала выгружаются скрипты, и всё считается в браузере у клиента.
Можете скачать zip-архив, отключить интернет и проверить в браузере.
Фича работает с жесткого диска, и переносима (portable).
Изначально, страница была скопипащена - отсюда: https://multiexplorer.com/paper_wallet/
Но их сайт чё-то не открывается, у них убунта упала, а вот логотипы ещё доступны:
https://multiexplorer.com/static/logos/1337-logo_100x100.png
Так вот, там, внутри страницы, был массив var crypto-data.
Переписал это дело, теперь, он в отдельном JS-файле: ./index_files/COINS_ARRAY.js
Чекбоксы запхнул в таблицу, написал цикл для построения этой таблицы по массиву.
Теперь эта таблица генерируется различной длины, при изменяемой длине массива с альткоинами.
Неиспользуемые альткоины можно закомментировать.
Также, есть возможность сгенерировать или получить
по парольной фразе мультикриптовалютный brainwallet.
Это список paperwallets для всех выбранных альткоинов,
приватные ключи для адресов которых, если их раскодировать из base58Check -
равны sha256 хешу от passphrase + nonce (которая задаётся в скрипте).
Поддержка сжатых ключей и адресов (compressed),
реализована при помощи библиотеки bitcoinjs-min.js от brainwallet'a.
Алсо, доступен поиск по массиву, при вводе адреса или приватного ключа - выводятся доступные альткоины. Пикрелейтед.
Прикрутил туда ещё вот это как усиление Math.random():
https://github.com/username1565/sha256-randomization
там внутри есть SHA256-функция.
Это OpenSource. Смотрите исходники файлов, они откомментированы внутри.
Хорошего настроения тебе, аноним...
Я вам принёс мультикриптовалютный паперваллет для различных альткоинов.
Вот он: https://username1565.github.io/MultiCoin-paperwallet/
Исходник - тут: https://github.com/username1565/MultiCoin-paperwallet/
Здесь, вы можете генерировать приватные ключи в WIF-формате,
в том числе и сжатые, для различных криптовалют (bitcoin-based altcoins).
Список настроек для различных альтов лежит в файле ./index_files/COINS_ARRAY.js
Только client-side вычисления. Никаких серверов, никой отправки данных куда-либо.
Даже если через сайт открываете, то сначала выгружаются скрипты, и всё считается в браузере у клиента.
Можете скачать zip-архив, отключить интернет и проверить в браузере.
Фича работает с жесткого диска, и переносима (portable).
Изначально, страница была скопипащена - отсюда: https://multiexplorer.com/paper_wallet/
Но их сайт чё-то не открывается, у них убунта упала, а вот логотипы ещё доступны:
https://multiexplorer.com/static/logos/1337-logo_100x100.png
Так вот, там, внутри страницы, был массив var crypto-data.
Переписал это дело, теперь, он в отдельном JS-файле: ./index_files/COINS_ARRAY.js
Чекбоксы запхнул в таблицу, написал цикл для построения этой таблицы по массиву.
Теперь эта таблица генерируется различной длины, при изменяемой длине массива с альткоинами.
Неиспользуемые альткоины можно закомментировать.
Также, есть возможность сгенерировать или получить
по парольной фразе мультикриптовалютный brainwallet.
Это список paperwallets для всех выбранных альткоинов,
приватные ключи для адресов которых, если их раскодировать из base58Check -
равны sha256 хешу от passphrase + nonce (которая задаётся в скрипте).
Поддержка сжатых ключей и адресов (compressed),
реализована при помощи библиотеки bitcoinjs-min.js от brainwallet'a.
Алсо, доступен поиск по массиву, при вводе адреса или приватного ключа - выводятся доступные альткоины. Пикрелейтед.
Прикрутил туда ещё вот это как усиление Math.random():
https://github.com/username1565/sha256-randomization
там внутри есть SHA256-функция.
Это OpenSource. Смотрите исходники файлов, они откомментированы внутри.
Хорошего настроения тебе, аноним...
>>393621 (OP)
Ахренеть
Ахренеть
>>393678
Вопрос обширный, но я поясню...
Там, у каждой монеты - разные префиксы, для приватного ключа и адреса,
поэтому ключи в WIF-формате (Base58Check) выглядят по разному, как и адреса.
А эллиптическая привая - одна, это https://en.bitcoin.it/wiki/Secp256k1
Её уравнение: y2 = x3 + 7
По-сути, приватный ключ - это 256-битное число (32 байта).
В этом генераторе - это хеш парольной фразы + nonce внутри скрипта,
которую я сделал многострочной с поддержкой Юникода.
После умножения этого числа (private key) - на генераторную точку G на эллиптической кривой
- получается другая точка, и её две координаты (большие числа x и y) - это публичный ключ.
Назад, с публичного ключа, получить приватный - сложно, в этом суть асимметричной криптографии.
Адрес - это хеш публичного ключа. Подробнее - здесь, на картинке внизу глянь: https://bits.media/bitcoin-address-theory/
У меня есть конвертер, вот здесь: https://username1565.github.io/brainwallet.github.io/#converter
И ты можешь сконвертировать любой сгенерированный приватный ключ - в HEX, чтобы убедиться, что это есть хеш,
тот самый, что над кнопкой, сгенерированный из парольной фразы или же перегенерированный из новой.
Под таблицей Source Text, в конвертере, после конвертации, ты увидишь и префикс приватного ключа.
Для сжатых приватных ключей в конце хеша, добавляется байт 01, hex содержит 33 байта, и адрес тогда - получается другой.
Всё потому что хешируется - не полный публичный ключ, а урезанная версия публичного ключа,
содержащего лишь одну координату x и байт чётности y кординаты (ведь при одной координате x, там могут быть - две точки на эллиптической кривой).
Исходя из всего вышеописанного, каждому приватному ключу - соответствует адрес.
Назад из адреса, получить приватный ключ сложно, если это вообще возможно.
Существуют адреса вообще без приватных ключей, их называют BURN-адресами, отправить туда монеты - всё равно что их сжечь.
При отправке транзакции с адреса - используется цифровая подпись по стандарту ECDSA.
Чтобы осуществить транзакцию - её надо подписать приватным ключём.
https://username1565.github.io/brainwallet.github.io/#verify?vrAddr=18w2rtYxYse12po93P1dkf8QnW8DaYqRTD&vrMsg=Работает цифровая подпись - примерно вот так...&vrSig=HHfepfGNwhjxfMYAVVJgLpn+sO98plrqy1MKOLybUwIeJArSkNEKuDJoqH1GIgpd/bKoqd/cOd9amcKLxIRjMo8=
А пару приватный ключ-адрес, можно генерировать локально. Даже бросив игральные кости, например.
Главное, чтобы всё это было правильно закодировано в Base58Check, и префиксы были правильно указаны,
и чтобы приватные ключи импортировались в кошельки, или web-wallet'ы типа https://blockchain.info/ или https://my.dogechain.info/
с которых можно платить без закачки различных програм.
Лично я использую консольную команду "importprivkey PRIVATE_KEY", в qt-кошельке - чтобы засунуть ключ и адрес,
и "dumpprivkey ADDRESS" - чтобы выписать приватный ключ на бумажку с последующим затиранием методом Питера Гуттмана - файла wallet.dat
Это очень полезно для долгосрочного HODL'a, в информационном поле, бушующем KeyStealer'ами.
Ты говоришь, что 2 одинаковых адреса не генерируется там?
А ты выбери одновременно, вот эти крипты:
{[0] Vertcoin, [6] Bitcoin, [7] Bitcoin Cash, [12] CounterParty, [17] Digibyte, [21] Emercoin, [29] Groestlcoin, [41] Namecoin}.
и сгенерируй. Увидишь одинаковые приватные ключи и адреса для некоторых. Их вид зависит от префиксных байт, указанных в массиве.
Этот генератор позволяет привязать множество приватных ключей и адресов (в том числе и сжатых)
для различных алькоинов (если правлильно ввести префиксы) - к простой парольной фразе,
без потери криптостойкости ключей (если указать хорошую, но секретную nonce в исходном коде скрипта).
При этом можно быстро, введя пароль, получить доступ к любому адресу, и узнать его приватный ключ по паролю,
затем импортировать его куда-то, заплатить с него (подписав ним транзакцию), или же с web-wallet's - облить монетами биржу.
Всё это, позволяет не хранить кучу файлов wallet.dat для каждой конкретной монеты,
а просто хранить в голове - парольную фразу.
Но зная nonce, можно устроить атаку по словарю, перебрав различные комбинации простых паролей, среди вероятных.
Поэтому, сам скрипт вместе с nonce может быть и зашифрован каким-нибудь AES.
У меня даже файл-енкриптор есть: https://username1565.github.io/javascript-file-encrypter/
С исходником, в придачу: https://github.com/username1565/javascript-file-encrypter
>Как это вообще работает?
Вопрос обширный, но я поясню...
Там, у каждой монеты - разные префиксы, для приватного ключа и адреса,
поэтому ключи в WIF-формате (Base58Check) выглядят по разному, как и адреса.
А эллиптическая привая - одна, это https://en.bitcoin.it/wiki/Secp256k1
Её уравнение: y2 = x3 + 7
По-сути, приватный ключ - это 256-битное число (32 байта).
В этом генераторе - это хеш парольной фразы + nonce внутри скрипта,
которую я сделал многострочной с поддержкой Юникода.
После умножения этого числа (private key) - на генераторную точку G на эллиптической кривой
- получается другая точка, и её две координаты (большие числа x и y) - это публичный ключ.
Назад, с публичного ключа, получить приватный - сложно, в этом суть асимметричной криптографии.
Адрес - это хеш публичного ключа. Подробнее - здесь, на картинке внизу глянь: https://bits.media/bitcoin-address-theory/
У меня есть конвертер, вот здесь: https://username1565.github.io/brainwallet.github.io/#converter
И ты можешь сконвертировать любой сгенерированный приватный ключ - в HEX, чтобы убедиться, что это есть хеш,
тот самый, что над кнопкой, сгенерированный из парольной фразы или же перегенерированный из новой.
Под таблицей Source Text, в конвертере, после конвертации, ты увидишь и префикс приватного ключа.
Для сжатых приватных ключей в конце хеша, добавляется байт 01, hex содержит 33 байта, и адрес тогда - получается другой.
Всё потому что хешируется - не полный публичный ключ, а урезанная версия публичного ключа,
содержащего лишь одну координату x и байт чётности y кординаты (ведь при одной координате x, там могут быть - две точки на эллиптической кривой).
Исходя из всего вышеописанного, каждому приватному ключу - соответствует адрес.
Назад из адреса, получить приватный ключ сложно, если это вообще возможно.
Существуют адреса вообще без приватных ключей, их называют BURN-адресами, отправить туда монеты - всё равно что их сжечь.
При отправке транзакции с адреса - используется цифровая подпись по стандарту ECDSA.
Чтобы осуществить транзакцию - её надо подписать приватным ключём.
https://username1565.github.io/brainwallet.github.io/#verify?vrAddr=18w2rtYxYse12po93P1dkf8QnW8DaYqRTD&vrMsg=Работает цифровая подпись - примерно вот так...&vrSig=HHfepfGNwhjxfMYAVVJgLpn+sO98plrqy1MKOLybUwIeJArSkNEKuDJoqH1GIgpd/bKoqd/cOd9amcKLxIRjMo8=
А пару приватный ключ-адрес, можно генерировать локально. Даже бросив игральные кости, например.
Главное, чтобы всё это было правильно закодировано в Base58Check, и префиксы были правильно указаны,
и чтобы приватные ключи импортировались в кошельки, или web-wallet'ы типа https://blockchain.info/ или https://my.dogechain.info/
с которых можно платить без закачки различных програм.
Лично я использую консольную команду "importprivkey PRIVATE_KEY", в qt-кошельке - чтобы засунуть ключ и адрес,
и "dumpprivkey ADDRESS" - чтобы выписать приватный ключ на бумажку с последующим затиранием методом Питера Гуттмана - файла wallet.dat
Это очень полезно для долгосрочного HODL'a, в информационном поле, бушующем KeyStealer'ами.
Ты говоришь, что 2 одинаковых адреса не генерируется там?
А ты выбери одновременно, вот эти крипты:
{[0] Vertcoin, [6] Bitcoin, [7] Bitcoin Cash, [12] CounterParty, [17] Digibyte, [21] Emercoin, [29] Groestlcoin, [41] Namecoin}.
и сгенерируй. Увидишь одинаковые приватные ключи и адреса для некоторых. Их вид зависит от префиксных байт, указанных в массиве.
Этот генератор позволяет привязать множество приватных ключей и адресов (в том числе и сжатых)
для различных алькоинов (если правлильно ввести префиксы) - к простой парольной фразе,
без потери криптостойкости ключей (если указать хорошую, но секретную nonce в исходном коде скрипта).
При этом можно быстро, введя пароль, получить доступ к любому адресу, и узнать его приватный ключ по паролю,
затем импортировать его куда-то, заплатить с него (подписав ним транзакцию), или же с web-wallet's - облить монетами биржу.
Всё это, позволяет не хранить кучу файлов wallet.dat для каждой конкретной монеты,
а просто хранить в голове - парольную фразу.
Но зная nonce, можно устроить атаку по словарю, перебрав различные комбинации простых паролей, среди вероятных.
Поэтому, сам скрипт вместе с nonce может быть и зашифрован каким-нибудь AES.
У меня даже файл-енкриптор есть: https://username1565.github.io/javascript-file-encrypter/
С исходником, в придачу: https://github.com/username1565/javascript-file-encrypter
>>393678
Вопрос обширный, но я поясню...
Там, у каждой монеты - разные префиксы, для приватного ключа и адреса,
поэтому ключи в WIF-формате (Base58Check) выглядят по разному, как и адреса.
А эллиптическая привая - одна, это https://en.bitcoin.it/wiki/Secp256k1
Её уравнение: y2 = x3 + 7
По-сути, приватный ключ - это 256-битное число (32 байта).
В этом генераторе - это хеш парольной фразы + nonce внутри скрипта,
которую я сделал многострочной с поддержкой Юникода.
После умножения этого числа (private key) - на генераторную точку G на эллиптической кривой
- получается другая точка, и её две координаты (большие числа x и y) - это публичный ключ.
Назад, с публичного ключа, получить приватный - сложно, в этом суть асимметричной криптографии.
Адрес - это хеш публичного ключа. Подробнее - здесь, на картинке внизу глянь: https://bits.media/bitcoin-address-theory/
У меня есть конвертер, вот здесь: https://username1565.github.io/brainwallet.github.io/#converter
И ты можешь сконвертировать любой сгенерированный приватный ключ - в HEX, чтобы убедиться, что это есть хеш,
тот самый, что над кнопкой, сгенерированный из парольной фразы или же перегенерированный из новой.
Под таблицей Source Text, в конвертере, после конвертации, ты увидишь и префикс приватного ключа.
Для сжатых приватных ключей в конце хеша, добавляется байт 01, hex содержит 33 байта, и адрес тогда - получается другой.
Всё потому что хешируется - не полный публичный ключ, а урезанная версия публичного ключа,
содержащего лишь одну координату x и байт чётности y кординаты (ведь при одной координате x, там могут быть - две точки на эллиптической кривой).
Исходя из всего вышеописанного, каждому приватному ключу - соответствует адрес.
Назад из адреса, получить приватный ключ сложно, если это вообще возможно.
Существуют адреса вообще без приватных ключей, их называют BURN-адресами, отправить туда монеты - всё равно что их сжечь.
При отправке транзакции с адреса - используется цифровая подпись по стандарту ECDSA.
Чтобы осуществить транзакцию - её надо подписать приватным ключём.
https://username1565.github.io/brainwallet.github.io/#verify?vrAddr=18w2rtYxYse12po93P1dkf8QnW8DaYqRTD&vrMsg=Работает цифровая подпись - примерно вот так...&vrSig=HHfepfGNwhjxfMYAVVJgLpn+sO98plrqy1MKOLybUwIeJArSkNEKuDJoqH1GIgpd/bKoqd/cOd9amcKLxIRjMo8=
А пару приватный ключ-адрес, можно генерировать локально. Даже бросив игральные кости, например.
Главное, чтобы всё это было правильно закодировано в Base58Check, и префиксы были правильно указаны,
и чтобы приватные ключи импортировались в кошельки, или web-wallet'ы типа https://blockchain.info/ или https://my.dogechain.info/
с которых можно платить без закачки различных програм.
Лично я использую консольную команду "importprivkey PRIVATE_KEY", в qt-кошельке - чтобы засунуть ключ и адрес,
и "dumpprivkey ADDRESS" - чтобы выписать приватный ключ на бумажку с последующим затиранием методом Питера Гуттмана - файла wallet.dat
Это очень полезно для долгосрочного HODL'a, в информационном поле, бушующем KeyStealer'ами.
Ты говоришь, что 2 одинаковых адреса не генерируется там?
А ты выбери одновременно, вот эти крипты:
{[0] Vertcoin, [6] Bitcoin, [7] Bitcoin Cash, [12] CounterParty, [17] Digibyte, [21] Emercoin, [29] Groestlcoin, [41] Namecoin}.
и сгенерируй. Увидишь одинаковые приватные ключи и адреса для некоторых. Их вид зависит от префиксных байт, указанных в массиве.
Этот генератор позволяет привязать множество приватных ключей и адресов (в том числе и сжатых)
для различных алькоинов (если правлильно ввести префиксы) - к простой парольной фразе,
без потери криптостойкости ключей (если указать хорошую, но секретную nonce в исходном коде скрипта).
При этом можно быстро, введя пароль, получить доступ к любому адресу, и узнать его приватный ключ по паролю,
затем импортировать его куда-то, заплатить с него (подписав ним транзакцию), или же с web-wallet's - облить монетами биржу.
Всё это, позволяет не хранить кучу файлов wallet.dat для каждой конкретной монеты,
а просто хранить в голове - парольную фразу.
Но зная nonce, можно устроить атаку по словарю, перебрав различные комбинации простых паролей, среди вероятных.
Поэтому, сам скрипт вместе с nonce может быть и зашифрован каким-нибудь AES.
У меня даже файл-енкриптор есть: https://username1565.github.io/javascript-file-encrypter/
С исходником, в придачу: https://github.com/username1565/javascript-file-encrypter
>Как это вообще работает?
Вопрос обширный, но я поясню...
Там, у каждой монеты - разные префиксы, для приватного ключа и адреса,
поэтому ключи в WIF-формате (Base58Check) выглядят по разному, как и адреса.
А эллиптическая привая - одна, это https://en.bitcoin.it/wiki/Secp256k1
Её уравнение: y2 = x3 + 7
По-сути, приватный ключ - это 256-битное число (32 байта).
В этом генераторе - это хеш парольной фразы + nonce внутри скрипта,
которую я сделал многострочной с поддержкой Юникода.
После умножения этого числа (private key) - на генераторную точку G на эллиптической кривой
- получается другая точка, и её две координаты (большие числа x и y) - это публичный ключ.
Назад, с публичного ключа, получить приватный - сложно, в этом суть асимметричной криптографии.
Адрес - это хеш публичного ключа. Подробнее - здесь, на картинке внизу глянь: https://bits.media/bitcoin-address-theory/
У меня есть конвертер, вот здесь: https://username1565.github.io/brainwallet.github.io/#converter
И ты можешь сконвертировать любой сгенерированный приватный ключ - в HEX, чтобы убедиться, что это есть хеш,
тот самый, что над кнопкой, сгенерированный из парольной фразы или же перегенерированный из новой.
Под таблицей Source Text, в конвертере, после конвертации, ты увидишь и префикс приватного ключа.
Для сжатых приватных ключей в конце хеша, добавляется байт 01, hex содержит 33 байта, и адрес тогда - получается другой.
Всё потому что хешируется - не полный публичный ключ, а урезанная версия публичного ключа,
содержащего лишь одну координату x и байт чётности y кординаты (ведь при одной координате x, там могут быть - две точки на эллиптической кривой).
Исходя из всего вышеописанного, каждому приватному ключу - соответствует адрес.
Назад из адреса, получить приватный ключ сложно, если это вообще возможно.
Существуют адреса вообще без приватных ключей, их называют BURN-адресами, отправить туда монеты - всё равно что их сжечь.
При отправке транзакции с адреса - используется цифровая подпись по стандарту ECDSA.
Чтобы осуществить транзакцию - её надо подписать приватным ключём.
https://username1565.github.io/brainwallet.github.io/#verify?vrAddr=18w2rtYxYse12po93P1dkf8QnW8DaYqRTD&vrMsg=Работает цифровая подпись - примерно вот так...&vrSig=HHfepfGNwhjxfMYAVVJgLpn+sO98plrqy1MKOLybUwIeJArSkNEKuDJoqH1GIgpd/bKoqd/cOd9amcKLxIRjMo8=
А пару приватный ключ-адрес, можно генерировать локально. Даже бросив игральные кости, например.
Главное, чтобы всё это было правильно закодировано в Base58Check, и префиксы были правильно указаны,
и чтобы приватные ключи импортировались в кошельки, или web-wallet'ы типа https://blockchain.info/ или https://my.dogechain.info/
с которых можно платить без закачки различных програм.
Лично я использую консольную команду "importprivkey PRIVATE_KEY", в qt-кошельке - чтобы засунуть ключ и адрес,
и "dumpprivkey ADDRESS" - чтобы выписать приватный ключ на бумажку с последующим затиранием методом Питера Гуттмана - файла wallet.dat
Это очень полезно для долгосрочного HODL'a, в информационном поле, бушующем KeyStealer'ами.
Ты говоришь, что 2 одинаковых адреса не генерируется там?
А ты выбери одновременно, вот эти крипты:
{[0] Vertcoin, [6] Bitcoin, [7] Bitcoin Cash, [12] CounterParty, [17] Digibyte, [21] Emercoin, [29] Groestlcoin, [41] Namecoin}.
и сгенерируй. Увидишь одинаковые приватные ключи и адреса для некоторых. Их вид зависит от префиксных байт, указанных в массиве.
Этот генератор позволяет привязать множество приватных ключей и адресов (в том числе и сжатых)
для различных алькоинов (если правлильно ввести префиксы) - к простой парольной фразе,
без потери криптостойкости ключей (если указать хорошую, но секретную nonce в исходном коде скрипта).
При этом можно быстро, введя пароль, получить доступ к любому адресу, и узнать его приватный ключ по паролю,
затем импортировать его куда-то, заплатить с него (подписав ним транзакцию), или же с web-wallet's - облить монетами биржу.
Всё это, позволяет не хранить кучу файлов wallet.dat для каждой конкретной монеты,
а просто хранить в голове - парольную фразу.
Но зная nonce, можно устроить атаку по словарю, перебрав различные комбинации простых паролей, среди вероятных.
Поэтому, сам скрипт вместе с nonce может быть и зашифрован каким-нибудь AES.
У меня даже файл-енкриптор есть: https://username1565.github.io/javascript-file-encrypter/
С исходником, в придачу: https://github.com/username1565/javascript-file-encrypter
>>393735
Там, в массиве у даша - несжатый ключ: "compressed": false
А я писал про сжатые ключи (compressed): https://en.bitcoin.it/wiki/List_of_address_prefixes
Есть ещё Segwit-адреса, там модификация адреса, байтами [0x00, 0x14]: https://www.reddit.com/r/Bitcoin/comments/5f34rl/convert_normal_1_address_to_new_segwit_address/
И есть transparent-адреса (Для ZCash и прочих cryptocurrencies based on Zcash's zero-knowledge encryption) - у них t-addr. Например, VoteCoin, BitcoinZ, и прочие...
Есть ещё какой-то адрес, с тройки начинается, по-моему это Pay to Script Hash (P2SH), и ещё, я знаю, что на публичный ключ можно как-то платить.
Всего этого - нету здесь, но отчасти, есть вот здесь (Segwit-addr, transparent-addr):
https://username1565.github.io/brainwallet.github.io/#generator
и здесь (bitcoin address <-> t-addr):
https://username1565.github.io/brainwallet.github.io/#t_addr
Ну и конечно же, с адресами эфира и эфиротокенов -можно было бы работать тоже.
Насколько я знаю, в MyEtherWallet - импортируется 32-байтный hex, а значит - им может быть хеш и отсюда.
>Не везде добавляется 01 в конце. В деше вроде не добавляется
Там, в массиве у даша - несжатый ключ: "compressed": false
А я писал про сжатые ключи (compressed): https://en.bitcoin.it/wiki/List_of_address_prefixes
>Note that private keys for compressed and uncompressed bitcoin public keys use the same version byte.
>The reason for the compressed form starting with a different character is because a 0x01
>byte is appended to the private key before base58 encoding.
Есть ещё Segwit-адреса, там модификация адреса, байтами [0x00, 0x14]: https://www.reddit.com/r/Bitcoin/comments/5f34rl/convert_normal_1_address_to_new_segwit_address/
И есть transparent-адреса (Для ZCash и прочих cryptocurrencies based on Zcash's zero-knowledge encryption) - у них t-addr. Например, VoteCoin, BitcoinZ, и прочие...
Есть ещё какой-то адрес, с тройки начинается, по-моему это Pay to Script Hash (P2SH), и ещё, я знаю, что на публичный ключ можно как-то платить.
Всего этого - нету здесь, но отчасти, есть вот здесь (Segwit-addr, transparent-addr):
https://username1565.github.io/brainwallet.github.io/#generator
и здесь (bitcoin address <-> t-addr):
https://username1565.github.io/brainwallet.github.io/#t_addr
Ну и конечно же, с адресами эфира и эфиротокенов -можно было бы работать тоже.
Насколько я знаю, в MyEtherWallet - импортируется 32-байтный hex, а значит - им может быть хеш и отсюда.
>>393621 (OP)
Вот, нашёл таблицу с префиксными байтами других альткоинов:
https://github.com/libbitcoin/libbitcoin/wiki/Altcoin-Version-Mappings
Внизу, её можно видеть как BIP44 Altcoin Version Mapping Table.
mainnet version_WIF - префикс приватного ключа (decimal)
mainnet version_p2pkh - префиксный байт для адреса (decimal),
и рядом, в скобках - символ, который соответствует первому символу адреса.
Правда, тут не указано то, сжатые ли ключи с адресами или не сжатые (compressed/uncompressed)...
Есть где-нибудь подобные таблицы? На биржах, вроде-бы должны быть, ведь там адреса генерируются.
Вот, нашёл таблицу с префиксными байтами других альткоинов:
https://github.com/libbitcoin/libbitcoin/wiki/Altcoin-Version-Mappings
Внизу, её можно видеть как BIP44 Altcoin Version Mapping Table.
mainnet version_WIF - префикс приватного ключа (decimal)
mainnet version_p2pkh - префиксный байт для адреса (decimal),
и рядом, в скобках - символ, который соответствует первому символу адреса.
Правда, тут не указано то, сжатые ли ключи с адресами или не сжатые (compressed/uncompressed)...
Есть где-нибудь подобные таблицы? На биржах, вроде-бы должны быть, ведь там адреса генерируются.
>>393813
Зачем тебе таблица? Смотри исходники монет. Это обычно в chainparams.cpp лежит, там разные функции, смотри ту что для main net.
Алсо, хороший тред. Хорошо что ты все рпсписываешь
Зачем тебе таблица? Смотри исходники монет. Это обычно в chainparams.cpp лежит, там разные функции, смотри ту что для main net.
Алсо, хороший тред. Хорошо что ты все рпсписываешь
>>393840
О, спасибо! Да, я вижу там префиксные байты.
Но чё-то вручную извлекать их не очень хочется, хотелось бы таблицу, чтобы так:
"Забил её один раз, запомнил пароль, открыл это, получил из пароля адрес с привом и майнишь на него."
Я тут кстати, недавно ISAAC CSPRNG форкнул, и дополнил его парочкой примеров:
Вот исходник: https://github.com/username1565/isaac.js
Вот примеры: https://username1565.github.io/isaac.js/
Поговаривают, что он быстрый (в чём я убедился, генерируя bitmap'ы в больших canvas'ах),
и криптостойкий - для атаки надо перебрать от 4.67 10^1240 до 10^2466 (вот это я не проверял).
Думаю его прикрутить сюда, ибо у меня после каждого вызова Math.radom() меняется salt,
представляя из себя не такое уж большое число, но и при этом - каждый раз вызывается функция хеширования,
что влияет на скорость получения множества случайных чисел.
То есть canvas bitmap не так быстро можно сгенерировать, через этот генератор,
чтоб попытаться разглядеть всякие полосы, артефакты, повторы, и прочее,
что могло бы сделать уязвимым генерацию чисел, а значит и строковых паролей от них зависящих.
А ISAAC можно сидить не только числами, а прямо sha256-хешами в виде строк.
Я ещё видел вот здесь: https://github.com/davidbau/seedrandom
возможность задать статичный seed "hello." для Math.random() после чего она выдаёт постоянные значения.
Но в этом коде, скорее всего, дефолтная Math.random() функция переопределяется как RC4 PRNG.
Поэтому, смотрю в сторону ISAAC, если часто вызывать её, но это не так уж осмысленно сюда его пихать,
без большой нагрузки на количество вызовов функции Math.random().
Я же в MultiCoin paperwallet'e canvas'ы с миллионами пикселей не генерирую, а просто пароли.
О, спасибо! Да, я вижу там префиксные байты.
Но чё-то вручную извлекать их не очень хочется, хотелось бы таблицу, чтобы так:
"Забил её один раз, запомнил пароль, открыл это, получил из пароля адрес с привом и майнишь на него."
Я тут кстати, недавно ISAAC CSPRNG форкнул, и дополнил его парочкой примеров:
Вот исходник: https://github.com/username1565/isaac.js
Вот примеры: https://username1565.github.io/isaac.js/
Поговаривают, что он быстрый (в чём я убедился, генерируя bitmap'ы в больших canvas'ах),
и криптостойкий - для атаки надо перебрать от 4.67 10^1240 до 10^2466 (вот это я не проверял).
Думаю его прикрутить сюда, ибо у меня после каждого вызова Math.radom() меняется salt,
представляя из себя не такое уж большое число, но и при этом - каждый раз вызывается функция хеширования,
что влияет на скорость получения множества случайных чисел.
То есть canvas bitmap не так быстро можно сгенерировать, через этот генератор,
чтоб попытаться разглядеть всякие полосы, артефакты, повторы, и прочее,
что могло бы сделать уязвимым генерацию чисел, а значит и строковых паролей от них зависящих.
А ISAAC можно сидить не только числами, а прямо sha256-хешами в виде строк.
Я ещё видел вот здесь: https://github.com/davidbau/seedrandom
возможность задать статичный seed "hello." для Math.random() после чего она выдаёт постоянные значения.
Но в этом коде, скорее всего, дефолтная Math.random() функция переопределяется как RC4 PRNG.
Поэтому, смотрю в сторону ISAAC, если часто вызывать её, но это не так уж осмысленно сюда его пихать,
без большой нагрузки на количество вызовов функции Math.random().
Я же в MultiCoin paperwallet'e canvas'ы с миллионами пикселей не генерирую, а просто пароли.
>>393840
О, спасибо! Да, я вижу там префиксные байты.
Но чё-то вручную извлекать их не очень хочется, хотелось бы таблицу, чтобы так:
"Забил её один раз, запомнил пароль, открыл это, получил из пароля адрес с привом и майнишь на него."
Я тут кстати, недавно ISAAC CSPRNG форкнул, и дополнил его парочкой примеров:
Вот исходник: https://github.com/username1565/isaac.js
Вот примеры: https://username1565.github.io/isaac.js/
Поговаривают, что он быстрый (в чём я убедился, генерируя bitmap'ы в больших canvas'ах),
и криптостойкий - для атаки надо перебрать от 4.67 10^1240 до 10^2466 (вот это я не проверял).
Думаю его прикрутить сюда, ибо у меня после каждого вызова Math.radom() меняется salt,
представляя из себя не такое уж большое число, но и при этом - каждый раз вызывается функция хеширования,
что влияет на скорость получения множества случайных чисел.
То есть canvas bitmap не так быстро можно сгенерировать, через этот генератор,
чтоб попытаться разглядеть всякие полосы, артефакты, повторы, и прочее,
что могло бы сделать уязвимым генерацию чисел, а значит и строковых паролей от них зависящих.
А ISAAC можно сидить не только числами, а прямо sha256-хешами в виде строк.
Я ещё видел вот здесь: https://github.com/davidbau/seedrandom
возможность задать статичный seed "hello." для Math.random() после чего она выдаёт постоянные значения.
Но в этом коде, скорее всего, дефолтная Math.random() функция переопределяется как RC4 PRNG.
Поэтому, смотрю в сторону ISAAC, если часто вызывать её, но это не так уж осмысленно сюда его пихать,
без большой нагрузки на количество вызовов функции Math.random().
Я же в MultiCoin paperwallet'e canvas'ы с миллионами пикселей не генерирую, а просто пароли.
О, спасибо! Да, я вижу там префиксные байты.
Но чё-то вручную извлекать их не очень хочется, хотелось бы таблицу, чтобы так:
"Забил её один раз, запомнил пароль, открыл это, получил из пароля адрес с привом и майнишь на него."
Я тут кстати, недавно ISAAC CSPRNG форкнул, и дополнил его парочкой примеров:
Вот исходник: https://github.com/username1565/isaac.js
Вот примеры: https://username1565.github.io/isaac.js/
Поговаривают, что он быстрый (в чём я убедился, генерируя bitmap'ы в больших canvas'ах),
и криптостойкий - для атаки надо перебрать от 4.67 10^1240 до 10^2466 (вот это я не проверял).
Думаю его прикрутить сюда, ибо у меня после каждого вызова Math.radom() меняется salt,
представляя из себя не такое уж большое число, но и при этом - каждый раз вызывается функция хеширования,
что влияет на скорость получения множества случайных чисел.
То есть canvas bitmap не так быстро можно сгенерировать, через этот генератор,
чтоб попытаться разглядеть всякие полосы, артефакты, повторы, и прочее,
что могло бы сделать уязвимым генерацию чисел, а значит и строковых паролей от них зависящих.
А ISAAC можно сидить не только числами, а прямо sha256-хешами в виде строк.
Я ещё видел вот здесь: https://github.com/davidbau/seedrandom
возможность задать статичный seed "hello." для Math.random() после чего она выдаёт постоянные значения.
Но в этом коде, скорее всего, дефолтная Math.random() функция переопределяется как RC4 PRNG.
Поэтому, смотрю в сторону ISAAC, если часто вызывать её, но это не так уж осмысленно сюда его пихать,
без большой нагрузки на количество вызовов функции Math.random().
Я же в MultiCoin paperwallet'e canvas'ы с миллионами пикселей не генерирую, а просто пароли.
Если набрать словарей с паролями, можно нагенерировать списки адресов (браинваллеты), сделав ключи из хешей паролей, а потом проверять, есть ли на них балансы. Когда это впервые сделали, обнаружились жирные балансы на некоторых адресах, полученных из фраз наподобие лиса перепрыгнула через ленивую собаку и т.п. Три года назад делал аналогичное для некоторых других топовых монет, но ничего не нашел.
>>394664
Других по отношению к биткоину.
Других по отношению к биткоину.
>>394664
Вот поэтому, я туда, в исходный код, многострочную nonce и засунул,
чтобы каждый мог переопределить её у себя перед генерацией ключей и адресов.
Кстати, как видишь, на этом сайте: https://brainwalletx.github.io/
есть предупреждение Important Security Update!,
ведущее на тред https://bitcointalk.org/index.php?topic=1148611.0
Этот тред создан в 2015-м году, когда биткоин стоил лишь около трехсот долларов, и не был так популярен,
каким он стал сейчас, когда его разнесли основной монетой - на все вот эти биржи:
https://coinmarketcap.com/rankings/exchanges/
В этом треде, в основном обсуждаются то, что отсутствует генератор случайных чисел, и/или то, что он уязвим.
Я вижу в исходном коде здесь: https://github.com/brainwalletX/brainwalletX.github.io/tree/master/js
файл secure-random.js
вот его исходник: https://github.com/brainwalletX/brainwalletX.github.io/blob/master/js/secure-random.js
внутри которого видно, что он собирает рандом либо с ноды:
nodeRandom(count, options)
crypto.randomBytes(count)
либо с браузера:
browserRandom(count, options)
var crypto = window.crypto || window.msCrypto
crypto.getRandomValues(nativeArr)
И криптостойкость значений на выходе этих функций напрямую зависят от исходного кода, внутри них.
Если там PRNG засунули, обозвав его вот так, то будет вызываться PRNG, поэтому надо декомпилировать исходники смотреть их и исправлять.
Кстати, подозреваю, что в qt-кошельках, когда адрес меняется, тоже используется PRNG,
и если узнать изначальный seed, то наверняка можно получить длинный список адресов, наподобие armory и electrum chains:
https://username1565.github.io/brainwallet.github.io/#chains
Вот поэтому, я туда, в исходный код, многострочную nonce и засунул,
чтобы каждый мог переопределить её у себя перед генерацией ключей и адресов.
Кстати, как видишь, на этом сайте: https://brainwalletx.github.io/
есть предупреждение Important Security Update!,
ведущее на тред https://bitcointalk.org/index.php?topic=1148611.0
Этот тред создан в 2015-м году, когда биткоин стоил лишь около трехсот долларов, и не был так популярен,
каким он стал сейчас, когда его разнесли основной монетой - на все вот эти биржи:
https://coinmarketcap.com/rankings/exchanges/
В этом треде, в основном обсуждаются то, что отсутствует генератор случайных чисел, и/или то, что он уязвим.
Я вижу в исходном коде здесь: https://github.com/brainwalletX/brainwalletX.github.io/tree/master/js
файл secure-random.js
вот его исходник: https://github.com/brainwalletX/brainwalletX.github.io/blob/master/js/secure-random.js
внутри которого видно, что он собирает рандом либо с ноды:
nodeRandom(count, options)
crypto.randomBytes(count)
либо с браузера:
browserRandom(count, options)
var crypto = window.crypto || window.msCrypto
crypto.getRandomValues(nativeArr)
И криптостойкость значений на выходе этих функций напрямую зависят от исходного кода, внутри них.
Если там PRNG засунули, обозвав его вот так, то будет вызываться PRNG, поэтому надо декомпилировать исходники смотреть их и исправлять.
Кстати, подозреваю, что в qt-кошельках, когда адрес меняется, тоже используется PRNG,
и если узнать изначальный seed, то наверняка можно получить длинный список адресов, наподобие armory и electrum chains:
https://username1565.github.io/brainwallet.github.io/#chains
78 Кб, 1343x618>>393621 (OP)
Аноны, если кто хочет таблички из бирж сортировать, но сортировка не прикручена там - я вам тут table sorter подвёз (пикрелейтед).
Тут можно его посмотреть: https://username1565.github.io/tablesorter/
а исходник - тут: https://github.com/username1565/tablesorter
Если кому надо JSON обрабатывать, например для поиска шустрейшей ноды по пингу тут: http://chainquery.com/bitcoin-api/getpeerinfo
можно заюзать это http://convertjson.com/json-to-html-table.htm
а потом скопировать в табличку, пхнуть её в сортер, и отсортировать по пингу.
Аноны, если кто хочет таблички из бирж сортировать, но сортировка не прикручена там - я вам тут table sorter подвёз (пикрелейтед).
Тут можно его посмотреть: https://username1565.github.io/tablesorter/
а исходник - тут: https://github.com/username1565/tablesorter
Если кому надо JSON обрабатывать, например для поиска шустрейшей ноды по пингу тут: http://chainquery.com/bitcoin-api/getpeerinfo
можно заюзать это http://convertjson.com/json-to-html-table.htm
а потом скопировать в табличку, пхнуть её в сортер, и отсортировать по пингу.
>>393621 (OP)
Криптаны! Вопрос технический!
Кто-нибудь может глянуть, в исходниках монет, код на плюсах,
в той части где подписи делаются и проверка подписей?
Я не очень-то понимаю синтаксис плюсов и не пойму где это.
Хочу, чтобы тут https://username1565.github.io/brainwallet.github.io/#verify
работала проверка подписей, для сообщений которые подписанны с qt-кошельков,
а она только на сайте работает, если с вкладки sign - во вкладку verify перенести подписанное сообщение.
Кошелёк же, сгенериррованную на сайте подпись - не может проверить,
также как подписанное сообщение кошельком - не проверяет сайт.
Там что-то подправить надо, никак не пойму что.
Вот исходник на Javascript: https://github.com/username1565/brainwallet.github.io/blob/master/js/bitcoinsig.js
Ну и сжатые-разжатые ключи с адресами ещё могут быть в подписи, с разными префиксами,
кроме одних лишь деволтных, расжатых...
Свиду, цифровая подпись и на сайте и в кошельке - имеет одинаковый формат,
она начинается с букв [H, I] и заканчивается знаком =,
но внутри, что-то надо таки-изменить, в самом brainwallet'e.
Криптаны! Вопрос технический!
Кто-нибудь может глянуть, в исходниках монет, код на плюсах,
в той части где подписи делаются и проверка подписей?
Я не очень-то понимаю синтаксис плюсов и не пойму где это.
Хочу, чтобы тут https://username1565.github.io/brainwallet.github.io/#verify
работала проверка подписей, для сообщений которые подписанны с qt-кошельков,
а она только на сайте работает, если с вкладки sign - во вкладку verify перенести подписанное сообщение.
Кошелёк же, сгенериррованную на сайте подпись - не может проверить,
также как подписанное сообщение кошельком - не проверяет сайт.
Там что-то подправить надо, никак не пойму что.
Вот исходник на Javascript: https://github.com/username1565/brainwallet.github.io/blob/master/js/bitcoinsig.js
Ну и сжатые-разжатые ключи с адресами ещё могут быть в подписи, с разными префиксами,
кроме одних лишь деволтных, расжатых...
Свиду, цифровая подпись и на сайте и в кошельке - имеет одинаковый формат,
она начинается с букв [H, I] и заканчивается знаком =,
но внутри, что-то надо таки-изменить, в самом brainwallet'e.
>>397494
Это были символы и пиксели.
Это были символы и пиксели.
>>393621 (OP)
там вирасы?
там вирасы?
>>393709
харошая штука, можно кого-нить грабануть на все манеты без гемороя, а вообще для чего нужна эта хуйня?
>wallet.dat для каждой конкретной монеты,
>а просто хранить в голове - парольную фразу.
харошая штука, можно кого-нить грабануть на все манеты без гемороя, а вообще для чего нужна эта хуйня?
>>397505
Хуирасы. Отнеси на virustotal, да проверь чё ты как маленький?
>>397506
Грабануть можно и KeyStealer'ом, шустро прочесав твой хард,
когда этот пост позабудешь и в ремонт свой винтец отнесёшь.
А парольную фразу ещё выбить в башки надо, и терморектальный криптоанализ - не всегда тут прокатит,
ведь она может быть хешем картинки или хешем надцати триллионов простых чисел.
Хуирасы. Отнеси на virustotal, да проверь чё ты как маленький?
>>397506
Грабануть можно и KeyStealer'ом, шустро прочесав твой хард,
когда этот пост позабудешь и в ремонт свой винтец отнесёшь.
А парольную фразу ещё выбить в башки надо, и терморектальный криптоанализ - не всегда тут прокатит,
ведь она может быть хешем картинки или хешем надцати триллионов простых чисел.
>>397506
А чтоб wallet.dat'ы от альтов не хранить (вместе с их кошельками). Ты хоть видел сколько их в природе бывает?
Там внутри, этих wallet.dat, которые могут быть encrypted, и затёрты всякими вирусами - только приватный ключ от адреса с балансом важен,
остальные же килобайты, от сгенерированных промежуточных адресов - нафиг не нужны.
Получить приватный ключ можно при помощи консольной команды:
Но записывать их все в текстовый файл - для всех альткоинов не очень удобно, если ты майнер с whattomine.com
Проще сгенерировать их, завязав на пароль да посолив (для криптостойкости)
Что и реализовано тут. Так вот, не хуйня это, а фича и она client-side.
Даже в brainwallet, ты не сгенерируешь пачку адресов от ВСЕХ альтов,
там можно только chains для одиночной крипты генерировать.
Ну и на биржах, примерно так адреса для депозита генерируются...
Кстати, между прочим, я вижу, что https://multiexplorer.com/ заработал,
и теперь туда можно зайти, зарегистрироваться, и полазить в кабинете. Вкладка Wallet даёт такую возможность.
Там видно, что когда листаешь адреса, вперёд-назад, в кабинете, они не перегенерируются, а один раз сгенерированы.
Подозреваю, что они завязаны на Backup Mnemonic, из вкладки Wallet Settings.
Ну а насчёт вирусов хуирусов - смотрите же исходник, там чёрным по белому всё расписано, и не очень мудрёно.
>а вообще для чего нужна эта хуйня?
А чтоб wallet.dat'ы от альтов не хранить (вместе с их кошельками). Ты хоть видел сколько их в природе бывает?
Там внутри, этих wallet.dat, которые могут быть encrypted, и затёрты всякими вирусами - только приватный ключ от адреса с балансом важен,
остальные же килобайты, от сгенерированных промежуточных адресов - нафиг не нужны.
Получить приватный ключ можно при помощи консольной команды:
>dumpprivkey address
Но записывать их все в текстовый файл - для всех альткоинов не очень удобно, если ты майнер с whattomine.com
Проще сгенерировать их, завязав на пароль да посолив (для криптостойкости)
Что и реализовано тут. Так вот, не хуйня это, а фича и она client-side.
Даже в brainwallet, ты не сгенерируешь пачку адресов от ВСЕХ альтов,
там можно только chains для одиночной крипты генерировать.
Ну и на биржах, примерно так адреса для депозита генерируются...
Кстати, между прочим, я вижу, что https://multiexplorer.com/ заработал,
и теперь туда можно зайти, зарегистрироваться, и полазить в кабинете. Вкладка Wallet даёт такую возможность.
Там видно, что когда листаешь адреса, вперёд-назад, в кабинете, они не перегенерируются, а один раз сгенерированы.
Подозреваю, что они завязаны на Backup Mnemonic, из вкладки Wallet Settings.
Ну а насчёт вирусов хуирусов - смотрите же исходник, там чёрным по белому всё расписано, и не очень мудрёно.
>>397493
Готово, блеать!
https://github.com/username1565/brainwallet.github.io/commit/de17257d7dd1a444e47857852fc60a9c733ca818
Решением - оказался префикс в виде параметра strMessageMagic.
Готово, блеать!
https://github.com/username1565/brainwallet.github.io/commit/de17257d7dd1a444e47857852fc60a9c733ca818
Решением - оказался префикс в виде параметра strMessageMagic.
>>393621 (OP)
В этой статье https://medium.com/blockchain-education-network/how-to-write-stuff-on-the-blockchain-bdae1704f24d
описано, как можно примечания к платежам в блокчейн засовывать.
Реально рабочая тема, hex пишется в саму транзу и в блокчейн,
а потом его видно при помощи консольных команд:
"getrawtransaction TX_HASH" и "decoderawtransaction RAW_TX_HEX".
В этой статье https://medium.com/blockchain-education-network/how-to-write-stuff-on-the-blockchain-bdae1704f24d
описано, как можно примечания к платежам в блокчейн засовывать.
Реально рабочая тема, hex пишется в саму транзу и в блокчейн,
а потом его видно при помощи консольных команд:
"getrawtransaction TX_HASH" и "decoderawtransaction RAW_TX_HEX".
>>393621 (OP)
Криптач, смотри...
Вот здесь https://brainwalletx.github.io/#tx
изначально была предусмотрена, возможность создания транзакции, формирования из неё raw-транзакции,
цифровая подпись этой raw-транзакции, и отправка подписанной raw-транзакции в сеть биткоина,
через API сайта https://blockchain.info/
Далее, вот здесь: https://username1565.github.io/brainwallet.github.io
я организовал работу брайнваллета с различными альткоинами, после выбора какого-либо, из списка.
Префиксы, разные отображаются в "Coin parameters:" - на вкладке generator.
Цифровые подписи сообщений - тоже работают для альтов, и проверяются в кошельках.
Но с транзакциями - нихуя не понятно.
Для формирования транзакции и подписи её - есть отдельный скрипт:
https://github.com/username1565/brainwallet.github.io/blob/master/js/tx.js
там внутри функция this.rebuild с каким-то не очень последовательным кодом.
Дальше, вот здесь: https://bitcoincashjs.github.io/
я нашёл браузерный bitcoincashjs.0.1.7.min.js, который не требует node.js.
Конечно же я пошёл сразу на github: https://github.com/bitcoincashjs/bitcoincashjs/
форкнул весь репозитарий и добавил туда этот браузерный буфер: https://github.com/BatikhSouri/browser-buffer
а также пару тестов для браузерной версии - в папку dist: https://github.com/username1565/bitcoincashjs/tree/master/dist/browser_tests
В несжатом файле последней версии bitcoincash-0.1.10.js,
в коде внутри, я вижу более читабельный код функции
для подписи для транзакций:
и
Но всё-равно непонятно нихуя с префиксами для альтов.
Внимание, вопрос... Как сделать всё это - совместимым со всеми другими альткоинами?
Казалось бы, для чего? А ведь по-сути это уже веб-кошелек.
Достаточно запилить API для функции sendrawtransaction на каком-либо сервере,
чтоб ретранслировать и пушить потом - транзакции на ноды, к майнерам.
При этом для создания транзакции - не нужно устанавливать кошелек и качать блокчейн,
а достаточно лишь знать приватный ключ от адреса с балансом,
и возможно загрузить баланс с блок-explorer'a или сети,
как в веб-кошельках MyEtherWallet или Waves.
Также, можно было бы, вообще без интернета, зная баланс и неизрасходованный выход -
подписать raw-транзакцию скриптом, сохранить её в виде hex,
и когда появится возможность отправить её через консоль qt-кошелька (в интернет-клубе, например),
просто скопипастить быстро и отправить,
без всяких инсталляций, синхронизаций, importprivkey и -reindex, -rescan
Одно дело, если веб-кошелек доступен для одной монеты
и через централизованные сервисы, вроде https://my.dogechain.info/ (у которых могут в любой момент домен отобрать)...
Другое же дело, если веб-кошелек универсальный, поддерживает много монет,
к тому же он всегда с тобой, и работает при наличии одного лишь Интернета.
Можно было бы кстати, каким-то образом и список addnode вписать туда,
и отправлять транзакции - прямо на ноды, без всякой синхронизации.
Криптач, смотри...
Вот здесь https://brainwalletx.github.io/#tx
изначально была предусмотрена, возможность создания транзакции, формирования из неё raw-транзакции,
цифровая подпись этой raw-транзакции, и отправка подписанной raw-транзакции в сеть биткоина,
через API сайта https://blockchain.info/
Далее, вот здесь: https://username1565.github.io/brainwallet.github.io
я организовал работу брайнваллета с различными альткоинами, после выбора какого-либо, из списка.
Префиксы, разные отображаются в "Coin parameters:" - на вкладке generator.
Цифровые подписи сообщений - тоже работают для альтов, и проверяются в кошельках.
Но с транзакциями - нихуя не понятно.
Для формирования транзакции и подписи её - есть отдельный скрипт:
https://github.com/username1565/brainwallet.github.io/blob/master/js/tx.js
там внутри функция this.rebuild с каким-то не очень последовательным кодом.
Дальше, вот здесь: https://bitcoincashjs.github.io/
я нашёл браузерный bitcoincashjs.0.1.7.min.js, который не требует node.js.
Конечно же я пошёл сразу на github: https://github.com/bitcoincashjs/bitcoincashjs/
форкнул весь репозитарий и добавил туда этот браузерный буфер: https://github.com/BatikhSouri/browser-buffer
а также пару тестов для браузерной версии - в папку dist: https://github.com/username1565/bitcoincashjs/tree/master/dist/browser_tests
В несжатом файле последней версии bitcoincash-0.1.10.js,
в коде внутри, я вижу более читабельный код функции
для подписи для транзакций:
>Transaction.prototype.sign
>this.getSignatures(privateKey, sigtype)
и
>input.getSignatures(transaction, privKey, index, sigtype, hashData)
Но всё-равно непонятно нихуя с префиксами для альтов.
Внимание, вопрос... Как сделать всё это - совместимым со всеми другими альткоинами?
Казалось бы, для чего? А ведь по-сути это уже веб-кошелек.
Достаточно запилить API для функции sendrawtransaction на каком-либо сервере,
чтоб ретранслировать и пушить потом - транзакции на ноды, к майнерам.
При этом для создания транзакции - не нужно устанавливать кошелек и качать блокчейн,
а достаточно лишь знать приватный ключ от адреса с балансом,
и возможно загрузить баланс с блок-explorer'a или сети,
как в веб-кошельках MyEtherWallet или Waves.
Также, можно было бы, вообще без интернета, зная баланс и неизрасходованный выход -
подписать raw-транзакцию скриптом, сохранить её в виде hex,
и когда появится возможность отправить её через консоль qt-кошелька (в интернет-клубе, например),
просто скопипастить быстро и отправить,
без всяких инсталляций, синхронизаций, importprivkey и -reindex, -rescan
Одно дело, если веб-кошелек доступен для одной монеты
и через централизованные сервисы, вроде https://my.dogechain.info/ (у которых могут в любой момент домен отобрать)...
Другое же дело, если веб-кошелек универсальный, поддерживает много монет,
к тому же он всегда с тобой, и работает при наличии одного лишь Интернета.
Можно было бы кстати, каким-то образом и список addnode вписать туда,
и отправлять транзакции - прямо на ноды, без всякой синхронизации.
>>393621 (OP)
Криптач, смотри...
Вот здесь https://brainwalletx.github.io/#tx
изначально была предусмотрена, возможность создания транзакции, формирования из неё raw-транзакции,
цифровая подпись этой raw-транзакции, и отправка подписанной raw-транзакции в сеть биткоина,
через API сайта https://blockchain.info/
Далее, вот здесь: https://username1565.github.io/brainwallet.github.io
я организовал работу брайнваллета с различными альткоинами, после выбора какого-либо, из списка.
Префиксы, разные отображаются в "Coin parameters:" - на вкладке generator.
Цифровые подписи сообщений - тоже работают для альтов, и проверяются в кошельках.
Но с транзакциями - нихуя не понятно.
Для формирования транзакции и подписи её - есть отдельный скрипт:
https://github.com/username1565/brainwallet.github.io/blob/master/js/tx.js
там внутри функция this.rebuild с каким-то не очень последовательным кодом.
Дальше, вот здесь: https://bitcoincashjs.github.io/
я нашёл браузерный bitcoincashjs.0.1.7.min.js, который не требует node.js.
Конечно же я пошёл сразу на github: https://github.com/bitcoincashjs/bitcoincashjs/
форкнул весь репозитарий и добавил туда этот браузерный буфер: https://github.com/BatikhSouri/browser-buffer
а также пару тестов для браузерной версии - в папку dist: https://github.com/username1565/bitcoincashjs/tree/master/dist/browser_tests
В несжатом файле последней версии bitcoincash-0.1.10.js,
в коде внутри, я вижу более читабельный код функции
для подписи для транзакций:
и
Но всё-равно непонятно нихуя с префиксами для альтов.
Внимание, вопрос... Как сделать всё это - совместимым со всеми другими альткоинами?
Казалось бы, для чего? А ведь по-сути это уже веб-кошелек.
Достаточно запилить API для функции sendrawtransaction на каком-либо сервере,
чтоб ретранслировать и пушить потом - транзакции на ноды, к майнерам.
При этом для создания транзакции - не нужно устанавливать кошелек и качать блокчейн,
а достаточно лишь знать приватный ключ от адреса с балансом,
и возможно загрузить баланс с блок-explorer'a или сети,
как в веб-кошельках MyEtherWallet или Waves.
Также, можно было бы, вообще без интернета, зная баланс и неизрасходованный выход -
подписать raw-транзакцию скриптом, сохранить её в виде hex,
и когда появится возможность отправить её через консоль qt-кошелька (в интернет-клубе, например),
просто скопипастить быстро и отправить,
без всяких инсталляций, синхронизаций, importprivkey и -reindex, -rescan
Одно дело, если веб-кошелек доступен для одной монеты
и через централизованные сервисы, вроде https://my.dogechain.info/ (у которых могут в любой момент домен отобрать)...
Другое же дело, если веб-кошелек универсальный, поддерживает много монет,
к тому же он всегда с тобой, и работает при наличии одного лишь Интернета.
Можно было бы кстати, каким-то образом и список addnode вписать туда,
и отправлять транзакции - прямо на ноды, без всякой синхронизации.
Криптач, смотри...
Вот здесь https://brainwalletx.github.io/#tx
изначально была предусмотрена, возможность создания транзакции, формирования из неё raw-транзакции,
цифровая подпись этой raw-транзакции, и отправка подписанной raw-транзакции в сеть биткоина,
через API сайта https://blockchain.info/
Далее, вот здесь: https://username1565.github.io/brainwallet.github.io
я организовал работу брайнваллета с различными альткоинами, после выбора какого-либо, из списка.
Префиксы, разные отображаются в "Coin parameters:" - на вкладке generator.
Цифровые подписи сообщений - тоже работают для альтов, и проверяются в кошельках.
Но с транзакциями - нихуя не понятно.
Для формирования транзакции и подписи её - есть отдельный скрипт:
https://github.com/username1565/brainwallet.github.io/blob/master/js/tx.js
там внутри функция this.rebuild с каким-то не очень последовательным кодом.
Дальше, вот здесь: https://bitcoincashjs.github.io/
я нашёл браузерный bitcoincashjs.0.1.7.min.js, который не требует node.js.
Конечно же я пошёл сразу на github: https://github.com/bitcoincashjs/bitcoincashjs/
форкнул весь репозитарий и добавил туда этот браузерный буфер: https://github.com/BatikhSouri/browser-buffer
а также пару тестов для браузерной версии - в папку dist: https://github.com/username1565/bitcoincashjs/tree/master/dist/browser_tests
В несжатом файле последней версии bitcoincash-0.1.10.js,
в коде внутри, я вижу более читабельный код функции
для подписи для транзакций:
>Transaction.prototype.sign
>this.getSignatures(privateKey, sigtype)
и
>input.getSignatures(transaction, privKey, index, sigtype, hashData)
Но всё-равно непонятно нихуя с префиксами для альтов.
Внимание, вопрос... Как сделать всё это - совместимым со всеми другими альткоинами?
Казалось бы, для чего? А ведь по-сути это уже веб-кошелек.
Достаточно запилить API для функции sendrawtransaction на каком-либо сервере,
чтоб ретранслировать и пушить потом - транзакции на ноды, к майнерам.
При этом для создания транзакции - не нужно устанавливать кошелек и качать блокчейн,
а достаточно лишь знать приватный ключ от адреса с балансом,
и возможно загрузить баланс с блок-explorer'a или сети,
как в веб-кошельках MyEtherWallet или Waves.
Также, можно было бы, вообще без интернета, зная баланс и неизрасходованный выход -
подписать raw-транзакцию скриптом, сохранить её в виде hex,
и когда появится возможность отправить её через консоль qt-кошелька (в интернет-клубе, например),
просто скопипастить быстро и отправить,
без всяких инсталляций, синхронизаций, importprivkey и -reindex, -rescan
Одно дело, если веб-кошелек доступен для одной монеты
и через централизованные сервисы, вроде https://my.dogechain.info/ (у которых могут в любой момент домен отобрать)...
Другое же дело, если веб-кошелек универсальный, поддерживает много монет,
к тому же он всегда с тобой, и работает при наличии одного лишь Интернета.
Можно было бы кстати, каким-то образом и список addnode вписать туда,
и отправлять транзакции - прямо на ноды, без всякой синхронизации.
>>403665
Просто напомню здесь про транзакцию с хешем 691dd277dc0e90a462a3d652a1171686de49cf19067cd33c7df0392833fb986a
Почитайте в гугле, что в ней закодировано.
Алсо, тут ещё пару транз красивых есть: https://github.com/nickmitchko/wikileaks/blob/master/jean_b.py
Просто напомню здесь про транзакцию с хешем 691dd277dc0e90a462a3d652a1171686de49cf19067cd33c7df0392833fb986a
Почитайте в гугле, что в ней закодировано.
Алсо, тут ещё пару транз красивых есть: https://github.com/nickmitchko/wikileaks/blob/master/jean_b.py
>>411423
ЫХХЫХЫЫХЫХЫЫЫЫЫХХХХ!
>python jean_b.py 08654f9dc9d673b3527b48ad06ab1b199ad47b61fd54033af30c2ee975c588bd ami-firmware-source-code-private-key-leaked.txt
ЫХХЫХЫЫХЫХЫЫЫЫЫХХХХ!
>>393621 (OP)
Как можно сделать красивый адрес? Типа там sup/cc/VQJejT6qBKTJcvhivzB6zbPKCdrAF
Как можно сделать красивый адрес? Типа там sup/cc/VQJejT6qBKTJcvhivzB6zbPKCdrAF
>>415212
vanitygen. В -help посмотри как префиксы передавать ему.
Ну и попытайся импортировать прив ещё, после генерации, чтоб сравнить импортированный адрес.
vanitygen. В -help посмотри как префиксы передавать ему.
Ну и попытайся импортировать прив ещё, после генерации, чтоб сравнить импортированный адрес.
>>393621 (OP)
https://github.com/username1565/MultiCoin-paperwallet/commit/57d602c632645b05486fc00cf7795c3a562bbfb6
Добавил кэфир с лого.
Спрятал привы и qr-коды от них под placeholder. Теперь, переключение - кликом по privkey.
Сделал zoom для qr-кодов, чтоб лучше сканировалось с экрана. Их теперь можно сохранить как PNG-файлы.
Вставил также на 832-й строке файла index.html - закомментированный огрызок кода для закачки qr-кодов
как GIF картинок, с отдельным генератором qrcode-generator.js и функцией generate_qr_code() .
Там можно задать урвень error correction capability "High".
Подправил чуток стили и запхнул туда ещё 40 разных спиннеров.
Теперь на страничке, при регенерации рандома - крутится протеиновый белок.
https://github.com/username1565/MultiCoin-paperwallet/commit/57d602c632645b05486fc00cf7795c3a562bbfb6
Добавил кэфир с лого.
Спрятал привы и qr-коды от них под placeholder. Теперь, переключение - кликом по privkey.
Сделал zoom для qr-кодов, чтоб лучше сканировалось с экрана. Их теперь можно сохранить как PNG-файлы.
Вставил также на 832-й строке файла index.html - закомментированный огрызок кода для закачки qr-кодов
как GIF картинок, с отдельным генератором qrcode-generator.js и функцией generate_qr_code() .
Там можно задать урвень error correction capability "High".
Подправил чуток стили и запхнул туда ещё 40 разных спиннеров.
Теперь на страничке, при регенерации рандома - крутится протеиновый белок.
>>393621 (OP)
Аноны, какой форк coinb.in из этих: https://github.com/OutCast3k/coinbin/network/members
Самый охуенный?
Ну, чтобы навороты всякие, и главное - чтобы транзы можно было подписывать client-side
и отправлять их через
https://live.blockcypher.com/btc/pushtx/
или
https://www.blockchain.com/ru/btc/pushtx
Есть чё-нибудь получше этого в сети?
Давайте-ка, всё это за-merge'им и сделаем заебатый, полнофункциональный веб-кошель для всех монет и токенов?
Аноны, какой форк coinb.in из этих: https://github.com/OutCast3k/coinbin/network/members
Самый охуенный?
Ну, чтобы навороты всякие, и главное - чтобы транзы можно было подписывать client-side
и отправлять их через
https://live.blockcypher.com/btc/pushtx/
или
https://www.blockchain.com/ru/btc/pushtx
Есть чё-нибудь получше этого в сети?
Давайте-ка, всё это за-merge'им и сделаем заебатый, полнофункциональный веб-кошель для всех монет и токенов?
>>415586
Нашёл вот этот форк: https://github.com/ttutdxh-nubits/cointoolkit
И он работает с транзами: https://nubits.com/cointoolkit/#verify
Нашёл вот этот форк: https://github.com/ttutdxh-nubits/cointoolkit
И он работает с транзами: https://nubits.com/cointoolkit/#verify
>>422620
Ну и хуле его сегдня арестовали? Сколько лет сидел в посольстве, никого не трогал, и на тебе...
Там это... Пароли от WikiLeaks "Insurance file" архивов ещё не вылились в сеть? Там, внутри инфа про Афган.
Ну и хуле его сегдня арестовали? Сколько лет сидел в посольстве, никого не трогал, и на тебе...
Там это... Пароли от WikiLeaks "Insurance file" архивов ещё не вылились в сеть? Там, внутри инфа про Афган.
![digitalsignature[1].png](https://2ch.hk//cc/src/393621/15590646944510.png)
![blobid1522844515331[1].jpg](https://2ch.hk//cc/src/393621/15590646944583.jpg)
>>393621 (OP)
Анон, давай вместе подумаем, как вытеснить с рынка фиат?!!
Сразу оговорюсь... Нахрена это надо? А просто для того - чтобы не срать транзами в блокчейн.
Фиат ходит из рук в руки, переносит микробы, но от этого же - не растут гигабайты на серверах и нодах!..
В общем, смотри, чем же пик2 и пик3 - не фиат, если на адресе - лежит реальный биток?
Ах, да, рандомный Антуан может скопировать private key и увести биток, оставляя никчёмную бумажку...
А что, если сделать что-то вроде скретч-карт (как карты пополнения у мобильных операторов)
то есть обычных карточек с адресом, и со скрытым под слоем - privkey?..
Тогда, баланс по адресу можно будет в любой момент, проверить, по сети - через блокчейн!
Ах да, а вот соответствие скрытого под защитным слоем privkey - указанному адресу,
увы, без рентгена - проверить нельзя...
То есть скамеры могут нарисовать там миллионы BTC, а под слоем намалякать рандом. Лол.
Тогда что, если сделать privkey - доступным только для считывателя (пик4), а не для чела.
Например, зашить privkey в RFID-метку, или сделать что-то вроде SIM-карты,
даже те же банковские карты - с чипами (пик2).
Действительно ведь, а нахрена в сим-картах и банковских картах, и даже паспортах - чипы? Там есть память? ДА!
Туда private key можно прошить, с него адрес получать, делая это:
либо в детекторе - при просвечивании купюры (с фиксированным номиналом),
либо в банкомате/терминале - при проверке карты,
и по блокчейну баланс по полученному адресу - сверять.
Тогда уже - никто не подделает такую купюру/карту...
В этом случае, в отличие от скретч-карт, уже можно проверить соответствие privkey - указанному адресу,
ведь с этого privkey - как раз и получается адрес.
Ах, да... Встаёт другой вопрос...
А что, если при считывании - считыватель втихую скопирует priv и стыбрит биткоин,
оставив держателю бесполезный пластик/бумажку?
Ну, очевидно, что если на купюре/карте указан адрес, которому соответствует этот же priv -
то держа карту/купюру - на руках, можно будет проверить баланс по адресу, через блокчейн.
В любой момент. Алсо, валидация купюры/карты, без баланса на ней, в следующий раз - уже не пройдёт.
Но всё-же, возможно что втихую всякие кардеры сольют биток. И это проблема.
Что тогда? Кувалдой банкомат идти бить?
Очевидно, что чтобы решить её - privkey нужно бы выдавать из чипа только тогда,
когда нужно РЕАЛЬНО ПОТРАТИТЬ BITCOIN с адреса...
И либо весь биткоин (в случае с купюрой фиксированного номинала),
либо часть биткоина - в случае с картой с чипом.
И да, кстати, privkey вообще выдавать из чипа не обязательно,
ведь для траты биткоинов - достаточно лишь подписать ним, исходящую с адреса - транзакцию,
и отправить её для подтверждения - в сеть, к майнерам.
К тому же, при работе с картой, privkey вообще выдавать не нужно,
ведь тратятся не все биткоины, и нужно бы только подписывать privkey'ем - транзакции,
и только при тратах, и только владельцем - возможно даже, после ввода обычного PIN-кода...
Дальше...
В случае исключения возмоности выдавать сам privkey из чипа (ну, чтоб его не скопировали втихаря),
встаёт проблема проверки самого адреса.
То есть: Как проверить баланс по адресу, privkey от которого - недоступен?
Или, же, вот так: Действительно ли privkey внутри чипа - соответствует указанному адресу?
Казалось бы, решением этой траблы являлась бы обычная распечатка адреса - прямо на карте/купюре
(bitcoin address вместо номера карты на пик2),
но это не решает вторую проблему... Ещё раз перефразирую её так:
Как знать, что privkey внутри чипа вообще там есть - и что он реально соответствует именно указанному адресу?
Или же, если окончательно перефразировать... То... Вопрос, скорее будет звучать так:
Каким же образом, можно проверить, наличие privkey в чипе
и соответствие указанного адреса - приватному ключу внутри чипа купюры/карты?
И тут решение оказывается очень простым!..
Раз уж в чипах есть память, то можно использовать обычную цифровую подпись (пик1), внутри самого чипа!
Алгоритм такой:
1. Сервер, терминал, банкомат, или детектор купюр (пик4) - хочет проверить валидность купюры с чипом, или баланс по карте (пик2).
2. Он посылает на чип купюры/карты, некое проверочное сообщение, например хэш даты и времени.
2. Внутри чипа, приватный ключ + сообщение - формируют цифровую подпись (пик1) и возвращают её в устройство из пункта 1.
3. Там, цифровая подпись - проверяется, и если она валидна, значит на чипе - содержится приватный ключ.
Проверка цифровой подписи происходит скриптами, с открытым исходным кодом, примерно вот так:
https://username1565.github.io/brainwallet.github.io/#verify?vrAddr=18w2rtYxYse12po93P1dkf8QnW8DaYqRTD&vrMsg=Date and time = 28.05.2019 17:19&vrSig=HH5KbJHAnyFT1FDENcvhoO7s3ZJXksLxF30Y2Zsfa+S1bbvYqhPkty0ndrcsr2qz4kpPL4JXobh5Jv4h/AbqR7Y=&vrstrMessageMagic=Bitcoin Signed Message:
Дальше, в устройстве из пункта 1, при поверке цифровой подписи,
помимо статуса о том, что подпись валидна - выдаётся ещё и адрес.
4. Затем, устройство из пункта 1, после получения адреса - просто проверяет баланс по адресу, в блокчейне:
Вот таким примерно образом: https://www.blockchain.com/btc/address/18w2rtYxYse12po93P1dkf8QnW8DaYqRTD
И если там есть монеты - то либо отображается баланс,
либо проходит валидация купюры с фиксированным номиналом (0.01 BTC, к примеру),
либо, может быть ещё перевод битков другому получателю (если это - терминал).
В случае перевода, указывается адрес получателя, в терминал засовывается купюра/карта с чипом,
внутри терминала - проверяется наличие приватного ключа в чипе, (через цифровую подпись),
затем приватным ключём из чипа - подписывается ТРАНЗАКЦИЯ перевода монет получателю,
а сама купюра - сгорает, то есть не возвращается из терминала,
и может буквально гореть (проходя вторичную переработку, внутри него, например).
Анон, давай вместе подумаем, как вытеснить с рынка фиат?!!
Сразу оговорюсь... Нахрена это надо? А просто для того - чтобы не срать транзами в блокчейн.
Фиат ходит из рук в руки, переносит микробы, но от этого же - не растут гигабайты на серверах и нодах!..
В общем, смотри, чем же пик2 и пик3 - не фиат, если на адресе - лежит реальный биток?
Ах, да, рандомный Антуан может скопировать private key и увести биток, оставляя никчёмную бумажку...
А что, если сделать что-то вроде скретч-карт (как карты пополнения у мобильных операторов)
то есть обычных карточек с адресом, и со скрытым под слоем - privkey?..
Тогда, баланс по адресу можно будет в любой момент, проверить, по сети - через блокчейн!
Ах да, а вот соответствие скрытого под защитным слоем privkey - указанному адресу,
увы, без рентгена - проверить нельзя...
То есть скамеры могут нарисовать там миллионы BTC, а под слоем намалякать рандом. Лол.
Тогда что, если сделать privkey - доступным только для считывателя (пик4), а не для чела.
Например, зашить privkey в RFID-метку, или сделать что-то вроде SIM-карты,
даже те же банковские карты - с чипами (пик2).
Действительно ведь, а нахрена в сим-картах и банковских картах, и даже паспортах - чипы? Там есть память? ДА!
Туда private key можно прошить, с него адрес получать, делая это:
либо в детекторе - при просвечивании купюры (с фиксированным номиналом),
либо в банкомате/терминале - при проверке карты,
и по блокчейну баланс по полученному адресу - сверять.
Тогда уже - никто не подделает такую купюру/карту...
В этом случае, в отличие от скретч-карт, уже можно проверить соответствие privkey - указанному адресу,
ведь с этого privkey - как раз и получается адрес.
Ах, да... Встаёт другой вопрос...
А что, если при считывании - считыватель втихую скопирует priv и стыбрит биткоин,
оставив держателю бесполезный пластик/бумажку?
Ну, очевидно, что если на купюре/карте указан адрес, которому соответствует этот же priv -
то держа карту/купюру - на руках, можно будет проверить баланс по адресу, через блокчейн.
В любой момент. Алсо, валидация купюры/карты, без баланса на ней, в следующий раз - уже не пройдёт.
Но всё-же, возможно что втихую всякие кардеры сольют биток. И это проблема.
Что тогда? Кувалдой банкомат идти бить?
Очевидно, что чтобы решить её - privkey нужно бы выдавать из чипа только тогда,
когда нужно РЕАЛЬНО ПОТРАТИТЬ BITCOIN с адреса...
И либо весь биткоин (в случае с купюрой фиксированного номинала),
либо часть биткоина - в случае с картой с чипом.
И да, кстати, privkey вообще выдавать из чипа не обязательно,
ведь для траты биткоинов - достаточно лишь подписать ним, исходящую с адреса - транзакцию,
и отправить её для подтверждения - в сеть, к майнерам.
К тому же, при работе с картой, privkey вообще выдавать не нужно,
ведь тратятся не все биткоины, и нужно бы только подписывать privkey'ем - транзакции,
и только при тратах, и только владельцем - возможно даже, после ввода обычного PIN-кода...
Дальше...
В случае исключения возмоности выдавать сам privkey из чипа (ну, чтоб его не скопировали втихаря),
встаёт проблема проверки самого адреса.
То есть: Как проверить баланс по адресу, privkey от которого - недоступен?
Или, же, вот так: Действительно ли privkey внутри чипа - соответствует указанному адресу?
Казалось бы, решением этой траблы являлась бы обычная распечатка адреса - прямо на карте/купюре
(bitcoin address вместо номера карты на пик2),
но это не решает вторую проблему... Ещё раз перефразирую её так:
Как знать, что privkey внутри чипа вообще там есть - и что он реально соответствует именно указанному адресу?
Или же, если окончательно перефразировать... То... Вопрос, скорее будет звучать так:
Каким же образом, можно проверить, наличие privkey в чипе
и соответствие указанного адреса - приватному ключу внутри чипа купюры/карты?
И тут решение оказывается очень простым!..
Раз уж в чипах есть память, то можно использовать обычную цифровую подпись (пик1), внутри самого чипа!
Алгоритм такой:
1. Сервер, терминал, банкомат, или детектор купюр (пик4) - хочет проверить валидность купюры с чипом, или баланс по карте (пик2).
2. Он посылает на чип купюры/карты, некое проверочное сообщение, например хэш даты и времени.
2. Внутри чипа, приватный ключ + сообщение - формируют цифровую подпись (пик1) и возвращают её в устройство из пункта 1.
3. Там, цифровая подпись - проверяется, и если она валидна, значит на чипе - содержится приватный ключ.
Проверка цифровой подписи происходит скриптами, с открытым исходным кодом, примерно вот так:
https://username1565.github.io/brainwallet.github.io/#verify?vrAddr=18w2rtYxYse12po93P1dkf8QnW8DaYqRTD&vrMsg=Date and time = 28.05.2019 17:19&vrSig=HH5KbJHAnyFT1FDENcvhoO7s3ZJXksLxF30Y2Zsfa+S1bbvYqhPkty0ndrcsr2qz4kpPL4JXobh5Jv4h/AbqR7Y=&vrstrMessageMagic=Bitcoin Signed Message:
Дальше, в устройстве из пункта 1, при поверке цифровой подписи,
помимо статуса о том, что подпись валидна - выдаётся ещё и адрес.
4. Затем, устройство из пункта 1, после получения адреса - просто проверяет баланс по адресу, в блокчейне:
Вот таким примерно образом: https://www.blockchain.com/btc/address/18w2rtYxYse12po93P1dkf8QnW8DaYqRTD
И если там есть монеты - то либо отображается баланс,
либо проходит валидация купюры с фиксированным номиналом (0.01 BTC, к примеру),
либо, может быть ещё перевод битков другому получателю (если это - терминал).
В случае перевода, указывается адрес получателя, в терминал засовывается купюра/карта с чипом,
внутри терминала - проверяется наличие приватного ключа в чипе, (через цифровую подпись),
затем приватным ключём из чипа - подписывается ТРАНЗАКЦИЯ перевода монет получателю,
а сама купюра - сгорает, то есть не возвращается из терминала,
и может буквально гореть (проходя вторичную переработку, внутри него, например).
>>393621 (OP)
Анон, давай вместе подумаем, как вытеснить с рынка фиат?!!
Сразу оговорюсь... Нахрена это надо? А просто для того - чтобы не срать транзами в блокчейн.
Фиат ходит из рук в руки, переносит микробы, но от этого же - не растут гигабайты на серверах и нодах!..
В общем, смотри, чем же пик2 и пик3 - не фиат, если на адресе - лежит реальный биток?
Ах, да, рандомный Антуан может скопировать private key и увести биток, оставляя никчёмную бумажку...
А что, если сделать что-то вроде скретч-карт (как карты пополнения у мобильных операторов)
то есть обычных карточек с адресом, и со скрытым под слоем - privkey?..
Тогда, баланс по адресу можно будет в любой момент, проверить, по сети - через блокчейн!
Ах да, а вот соответствие скрытого под защитным слоем privkey - указанному адресу,
увы, без рентгена - проверить нельзя...
То есть скамеры могут нарисовать там миллионы BTC, а под слоем намалякать рандом. Лол.
Тогда что, если сделать privkey - доступным только для считывателя (пик4), а не для чела.
Например, зашить privkey в RFID-метку, или сделать что-то вроде SIM-карты,
даже те же банковские карты - с чипами (пик2).
Действительно ведь, а нахрена в сим-картах и банковских картах, и даже паспортах - чипы? Там есть память? ДА!
Туда private key можно прошить, с него адрес получать, делая это:
либо в детекторе - при просвечивании купюры (с фиксированным номиналом),
либо в банкомате/терминале - при проверке карты,
и по блокчейну баланс по полученному адресу - сверять.
Тогда уже - никто не подделает такую купюру/карту...
В этом случае, в отличие от скретч-карт, уже можно проверить соответствие privkey - указанному адресу,
ведь с этого privkey - как раз и получается адрес.
Ах, да... Встаёт другой вопрос...
А что, если при считывании - считыватель втихую скопирует priv и стыбрит биткоин,
оставив держателю бесполезный пластик/бумажку?
Ну, очевидно, что если на купюре/карте указан адрес, которому соответствует этот же priv -
то держа карту/купюру - на руках, можно будет проверить баланс по адресу, через блокчейн.
В любой момент. Алсо, валидация купюры/карты, без баланса на ней, в следующий раз - уже не пройдёт.
Но всё-же, возможно что втихую всякие кардеры сольют биток. И это проблема.
Что тогда? Кувалдой банкомат идти бить?
Очевидно, что чтобы решить её - privkey нужно бы выдавать из чипа только тогда,
когда нужно РЕАЛЬНО ПОТРАТИТЬ BITCOIN с адреса...
И либо весь биткоин (в случае с купюрой фиксированного номинала),
либо часть биткоина - в случае с картой с чипом.
И да, кстати, privkey вообще выдавать из чипа не обязательно,
ведь для траты биткоинов - достаточно лишь подписать ним, исходящую с адреса - транзакцию,
и отправить её для подтверждения - в сеть, к майнерам.
К тому же, при работе с картой, privkey вообще выдавать не нужно,
ведь тратятся не все биткоины, и нужно бы только подписывать privkey'ем - транзакции,
и только при тратах, и только владельцем - возможно даже, после ввода обычного PIN-кода...
Дальше...
В случае исключения возмоности выдавать сам privkey из чипа (ну, чтоб его не скопировали втихаря),
встаёт проблема проверки самого адреса.
То есть: Как проверить баланс по адресу, privkey от которого - недоступен?
Или, же, вот так: Действительно ли privkey внутри чипа - соответствует указанному адресу?
Казалось бы, решением этой траблы являлась бы обычная распечатка адреса - прямо на карте/купюре
(bitcoin address вместо номера карты на пик2),
но это не решает вторую проблему... Ещё раз перефразирую её так:
Как знать, что privkey внутри чипа вообще там есть - и что он реально соответствует именно указанному адресу?
Или же, если окончательно перефразировать... То... Вопрос, скорее будет звучать так:
Каким же образом, можно проверить, наличие privkey в чипе
и соответствие указанного адреса - приватному ключу внутри чипа купюры/карты?
И тут решение оказывается очень простым!..
Раз уж в чипах есть память, то можно использовать обычную цифровую подпись (пик1), внутри самого чипа!
Алгоритм такой:
1. Сервер, терминал, банкомат, или детектор купюр (пик4) - хочет проверить валидность купюры с чипом, или баланс по карте (пик2).
2. Он посылает на чип купюры/карты, некое проверочное сообщение, например хэш даты и времени.
2. Внутри чипа, приватный ключ + сообщение - формируют цифровую подпись (пик1) и возвращают её в устройство из пункта 1.
3. Там, цифровая подпись - проверяется, и если она валидна, значит на чипе - содержится приватный ключ.
Проверка цифровой подписи происходит скриптами, с открытым исходным кодом, примерно вот так:
https://username1565.github.io/brainwallet.github.io/#verify?vrAddr=18w2rtYxYse12po93P1dkf8QnW8DaYqRTD&vrMsg=Date and time = 28.05.2019 17:19&vrSig=HH5KbJHAnyFT1FDENcvhoO7s3ZJXksLxF30Y2Zsfa+S1bbvYqhPkty0ndrcsr2qz4kpPL4JXobh5Jv4h/AbqR7Y=&vrstrMessageMagic=Bitcoin Signed Message:
Дальше, в устройстве из пункта 1, при поверке цифровой подписи,
помимо статуса о том, что подпись валидна - выдаётся ещё и адрес.
4. Затем, устройство из пункта 1, после получения адреса - просто проверяет баланс по адресу, в блокчейне:
Вот таким примерно образом: https://www.blockchain.com/btc/address/18w2rtYxYse12po93P1dkf8QnW8DaYqRTD
И если там есть монеты - то либо отображается баланс,
либо проходит валидация купюры с фиксированным номиналом (0.01 BTC, к примеру),
либо, может быть ещё перевод битков другому получателю (если это - терминал).
В случае перевода, указывается адрес получателя, в терминал засовывается купюра/карта с чипом,
внутри терминала - проверяется наличие приватного ключа в чипе, (через цифровую подпись),
затем приватным ключём из чипа - подписывается ТРАНЗАКЦИЯ перевода монет получателю,
а сама купюра - сгорает, то есть не возвращается из терминала,
и может буквально гореть (проходя вторичную переработку, внутри него, например).
Анон, давай вместе подумаем, как вытеснить с рынка фиат?!!
Сразу оговорюсь... Нахрена это надо? А просто для того - чтобы не срать транзами в блокчейн.
Фиат ходит из рук в руки, переносит микробы, но от этого же - не растут гигабайты на серверах и нодах!..
В общем, смотри, чем же пик2 и пик3 - не фиат, если на адресе - лежит реальный биток?
Ах, да, рандомный Антуан может скопировать private key и увести биток, оставляя никчёмную бумажку...
А что, если сделать что-то вроде скретч-карт (как карты пополнения у мобильных операторов)
то есть обычных карточек с адресом, и со скрытым под слоем - privkey?..
Тогда, баланс по адресу можно будет в любой момент, проверить, по сети - через блокчейн!
Ах да, а вот соответствие скрытого под защитным слоем privkey - указанному адресу,
увы, без рентгена - проверить нельзя...
То есть скамеры могут нарисовать там миллионы BTC, а под слоем намалякать рандом. Лол.
Тогда что, если сделать privkey - доступным только для считывателя (пик4), а не для чела.
Например, зашить privkey в RFID-метку, или сделать что-то вроде SIM-карты,
даже те же банковские карты - с чипами (пик2).
Действительно ведь, а нахрена в сим-картах и банковских картах, и даже паспортах - чипы? Там есть память? ДА!
Туда private key можно прошить, с него адрес получать, делая это:
либо в детекторе - при просвечивании купюры (с фиксированным номиналом),
либо в банкомате/терминале - при проверке карты,
и по блокчейну баланс по полученному адресу - сверять.
Тогда уже - никто не подделает такую купюру/карту...
В этом случае, в отличие от скретч-карт, уже можно проверить соответствие privkey - указанному адресу,
ведь с этого privkey - как раз и получается адрес.
Ах, да... Встаёт другой вопрос...
А что, если при считывании - считыватель втихую скопирует priv и стыбрит биткоин,
оставив держателю бесполезный пластик/бумажку?
Ну, очевидно, что если на купюре/карте указан адрес, которому соответствует этот же priv -
то держа карту/купюру - на руках, можно будет проверить баланс по адресу, через блокчейн.
В любой момент. Алсо, валидация купюры/карты, без баланса на ней, в следующий раз - уже не пройдёт.
Но всё-же, возможно что втихую всякие кардеры сольют биток. И это проблема.
Что тогда? Кувалдой банкомат идти бить?
Очевидно, что чтобы решить её - privkey нужно бы выдавать из чипа только тогда,
когда нужно РЕАЛЬНО ПОТРАТИТЬ BITCOIN с адреса...
И либо весь биткоин (в случае с купюрой фиксированного номинала),
либо часть биткоина - в случае с картой с чипом.
И да, кстати, privkey вообще выдавать из чипа не обязательно,
ведь для траты биткоинов - достаточно лишь подписать ним, исходящую с адреса - транзакцию,
и отправить её для подтверждения - в сеть, к майнерам.
К тому же, при работе с картой, privkey вообще выдавать не нужно,
ведь тратятся не все биткоины, и нужно бы только подписывать privkey'ем - транзакции,
и только при тратах, и только владельцем - возможно даже, после ввода обычного PIN-кода...
Дальше...
В случае исключения возмоности выдавать сам privkey из чипа (ну, чтоб его не скопировали втихаря),
встаёт проблема проверки самого адреса.
То есть: Как проверить баланс по адресу, privkey от которого - недоступен?
Или, же, вот так: Действительно ли privkey внутри чипа - соответствует указанному адресу?
Казалось бы, решением этой траблы являлась бы обычная распечатка адреса - прямо на карте/купюре
(bitcoin address вместо номера карты на пик2),
но это не решает вторую проблему... Ещё раз перефразирую её так:
Как знать, что privkey внутри чипа вообще там есть - и что он реально соответствует именно указанному адресу?
Или же, если окончательно перефразировать... То... Вопрос, скорее будет звучать так:
Каким же образом, можно проверить, наличие privkey в чипе
и соответствие указанного адреса - приватному ключу внутри чипа купюры/карты?
И тут решение оказывается очень простым!..
Раз уж в чипах есть память, то можно использовать обычную цифровую подпись (пик1), внутри самого чипа!
Алгоритм такой:
1. Сервер, терминал, банкомат, или детектор купюр (пик4) - хочет проверить валидность купюры с чипом, или баланс по карте (пик2).
2. Он посылает на чип купюры/карты, некое проверочное сообщение, например хэш даты и времени.
2. Внутри чипа, приватный ключ + сообщение - формируют цифровую подпись (пик1) и возвращают её в устройство из пункта 1.
3. Там, цифровая подпись - проверяется, и если она валидна, значит на чипе - содержится приватный ключ.
Проверка цифровой подписи происходит скриптами, с открытым исходным кодом, примерно вот так:
https://username1565.github.io/brainwallet.github.io/#verify?vrAddr=18w2rtYxYse12po93P1dkf8QnW8DaYqRTD&vrMsg=Date and time = 28.05.2019 17:19&vrSig=HH5KbJHAnyFT1FDENcvhoO7s3ZJXksLxF30Y2Zsfa+S1bbvYqhPkty0ndrcsr2qz4kpPL4JXobh5Jv4h/AbqR7Y=&vrstrMessageMagic=Bitcoin Signed Message:
Дальше, в устройстве из пункта 1, при поверке цифровой подписи,
помимо статуса о том, что подпись валидна - выдаётся ещё и адрес.
4. Затем, устройство из пункта 1, после получения адреса - просто проверяет баланс по адресу, в блокчейне:
Вот таким примерно образом: https://www.blockchain.com/btc/address/18w2rtYxYse12po93P1dkf8QnW8DaYqRTD
И если там есть монеты - то либо отображается баланс,
либо проходит валидация купюры с фиксированным номиналом (0.01 BTC, к примеру),
либо, может быть ещё перевод битков другому получателю (если это - терминал).
В случае перевода, указывается адрес получателя, в терминал засовывается купюра/карта с чипом,
внутри терминала - проверяется наличие приватного ключа в чипе, (через цифровую подпись),
затем приватным ключём из чипа - подписывается ТРАНЗАКЦИЯ перевода монет получателю,
а сама купюра - сгорает, то есть не возвращается из терминала,
и может буквально гореть (проходя вторичную переработку, внутри него, например).
>>429740
Однако, не забываем о том, что сами транзы - засирают блокчейн гигабайтами.
Если privkey не выдавать из чипа, а только подписывать транзакции ним, то очевидно наличие транзакций в сети bitcoin.
А вот с чипо-купюрами, с фиксированным номиналом, можно было бы и попроще...
Без транзакций, как с фиатом.
Сначала, купюра пожирается, инфа на чипе считывается, летит получателю в другой терминал, а ему вылазит такая же ровно - купюра,
затем инфа на чипе первой купюры - сбрасывается и она стаёт невалидной. Всё.
Так как privkey не знает ни владелец, ни получатель, он - один не меняется, является одним и тем же privkey,
но эта схема уязвима к перехвату этого privkey - терминалом, с последующим сливом c адреса купюры - биткоинового обеспечения.
В таком случае, купюра уже не пройдёт валидацию.
И хотя эта схема вообще без транзакций, как у фиата,
это пиздатый баг. Она может открывать дыру хакерам - для массовых скамов и сливов...
И чтобы чип не палил privkey - терминалу, очевидно, что можно было бы его шифровать асимметрично!
Например, при помощи PGP: https://username1565.github.io/pgp/
1. Получатель - генерирует пару ключей PGP, и держит в секрете свой PGP privkey.
2. Отправитель (владелец чипо-купюры), просит его подписать ним - некое проверочное сообщение.
3. Получатель подписывает privkey'eм сообщение, и отправляет его, вместе с PUB-key - отправителю.
4. Отправитель - вводит в терминал PGP-pubkey получателя, и проверяет цифровую подпись получателя,
тем самым - он убеждается, что приватный ключ PGP - имеется у получателя, а цифровая подпись - корректна.
5. При переводе монет получателю, отправитель пишет в терминале - просто его PGP-PUB-key,
причём - однократно, при проверке сообщения,
и этот PGP-PUB-key - он вводит, как адрес получателя.
6. Из терминала отправителя, этот PGP-PUB-key получателя - поступает уже на вход ЧИПА-купюры,
после чего, ЧИП ШИФРУЕТ инфу внутри себя - асимметрично, этим PGP-PUB-KEY, и выдаёт терминалу - шифр.
Терминал не знает саму инфу, и просто шлёт получателю криптоинфу, или заводит её в терминальную базу,
вместе с PUB-key получателя (по которому её можно найти).
После ввода PGP-PRIV-KEY, уже в своём терминале - получатель может расшифровать зашифрованную чипом отправителя инфу,
и тогда уже, его терминал, может записать её на такой же аналогичный чип - выдав получателю ту же купюру.
7. Инфа на чипе старой купюры - зануляется, а купюра отправителя - пожирается терминалом.
На неё, же, терминал может писать инфу для других получателей, делая с неё другие купюры.
Но тут, на этапе расшифровки - терминал может скопировать privkey.
И чтобы этого не было, он может залить сразу шифр в купюру, а активировать её для валидации,
можно было бы, введя свой секретный PGP-privkey при помощи специального устройства,
подключаемого к чипу купюры.
Тогда, PGP-privkey - поступает на вход чипа, с последующей дешифровкой чипом шифра - в инфу получателя,
и записью в этот чип изначального privkey.
Однако, не забываем о том, что сами транзы - засирают блокчейн гигабайтами.
Если privkey не выдавать из чипа, а только подписывать транзакции ним, то очевидно наличие транзакций в сети bitcoin.
А вот с чипо-купюрами, с фиксированным номиналом, можно было бы и попроще...
Без транзакций, как с фиатом.
Сначала, купюра пожирается, инфа на чипе считывается, летит получателю в другой терминал, а ему вылазит такая же ровно - купюра,
затем инфа на чипе первой купюры - сбрасывается и она стаёт невалидной. Всё.
Так как privkey не знает ни владелец, ни получатель, он - один не меняется, является одним и тем же privkey,
но эта схема уязвима к перехвату этого privkey - терминалом, с последующим сливом c адреса купюры - биткоинового обеспечения.
В таком случае, купюра уже не пройдёт валидацию.
И хотя эта схема вообще без транзакций, как у фиата,
это пиздатый баг. Она может открывать дыру хакерам - для массовых скамов и сливов...
И чтобы чип не палил privkey - терминалу, очевидно, что можно было бы его шифровать асимметрично!
Например, при помощи PGP: https://username1565.github.io/pgp/
1. Получатель - генерирует пару ключей PGP, и держит в секрете свой PGP privkey.
2. Отправитель (владелец чипо-купюры), просит его подписать ним - некое проверочное сообщение.
3. Получатель подписывает privkey'eм сообщение, и отправляет его, вместе с PUB-key - отправителю.
4. Отправитель - вводит в терминал PGP-pubkey получателя, и проверяет цифровую подпись получателя,
тем самым - он убеждается, что приватный ключ PGP - имеется у получателя, а цифровая подпись - корректна.
5. При переводе монет получателю, отправитель пишет в терминале - просто его PGP-PUB-key,
причём - однократно, при проверке сообщения,
и этот PGP-PUB-key - он вводит, как адрес получателя.
6. Из терминала отправителя, этот PGP-PUB-key получателя - поступает уже на вход ЧИПА-купюры,
после чего, ЧИП ШИФРУЕТ инфу внутри себя - асимметрично, этим PGP-PUB-KEY, и выдаёт терминалу - шифр.
Терминал не знает саму инфу, и просто шлёт получателю криптоинфу, или заводит её в терминальную базу,
вместе с PUB-key получателя (по которому её можно найти).
После ввода PGP-PRIV-KEY, уже в своём терминале - получатель может расшифровать зашифрованную чипом отправителя инфу,
и тогда уже, его терминал, может записать её на такой же аналогичный чип - выдав получателю ту же купюру.
7. Инфа на чипе старой купюры - зануляется, а купюра отправителя - пожирается терминалом.
На неё, же, терминал может писать инфу для других получателей, делая с неё другие купюры.
Но тут, на этапе расшифровки - терминал может скопировать privkey.
И чтобы этого не было, он может залить сразу шифр в купюру, а активировать её для валидации,
можно было бы, введя свой секретный PGP-privkey при помощи специального устройства,
подключаемого к чипу купюры.
Тогда, PGP-privkey - поступает на вход чипа, с последующей дешифровкой чипом шифра - в инфу получателя,
и записью в этот чип изначального privkey.
>>429740
Однако, не забываем о том, что сами транзы - засирают блокчейн гигабайтами.
Если privkey не выдавать из чипа, а только подписывать транзакции ним, то очевидно наличие транзакций в сети bitcoin.
А вот с чипо-купюрами, с фиксированным номиналом, можно было бы и попроще...
Без транзакций, как с фиатом.
Сначала, купюра пожирается, инфа на чипе считывается, летит получателю в другой терминал, а ему вылазит такая же ровно - купюра,
затем инфа на чипе первой купюры - сбрасывается и она стаёт невалидной. Всё.
Так как privkey не знает ни владелец, ни получатель, он - один не меняется, является одним и тем же privkey,
но эта схема уязвима к перехвату этого privkey - терминалом, с последующим сливом c адреса купюры - биткоинового обеспечения.
В таком случае, купюра уже не пройдёт валидацию.
И хотя эта схема вообще без транзакций, как у фиата,
это пиздатый баг. Она может открывать дыру хакерам - для массовых скамов и сливов...
И чтобы чип не палил privkey - терминалу, очевидно, что можно было бы его шифровать асимметрично!
Например, при помощи PGP: https://username1565.github.io/pgp/
1. Получатель - генерирует пару ключей PGP, и держит в секрете свой PGP privkey.
2. Отправитель (владелец чипо-купюры), просит его подписать ним - некое проверочное сообщение.
3. Получатель подписывает privkey'eм сообщение, и отправляет его, вместе с PUB-key - отправителю.
4. Отправитель - вводит в терминал PGP-pubkey получателя, и проверяет цифровую подпись получателя,
тем самым - он убеждается, что приватный ключ PGP - имеется у получателя, а цифровая подпись - корректна.
5. При переводе монет получателю, отправитель пишет в терминале - просто его PGP-PUB-key,
причём - однократно, при проверке сообщения,
и этот PGP-PUB-key - он вводит, как адрес получателя.
6. Из терминала отправителя, этот PGP-PUB-key получателя - поступает уже на вход ЧИПА-купюры,
после чего, ЧИП ШИФРУЕТ инфу внутри себя - асимметрично, этим PGP-PUB-KEY, и выдаёт терминалу - шифр.
Терминал не знает саму инфу, и просто шлёт получателю криптоинфу, или заводит её в терминальную базу,
вместе с PUB-key получателя (по которому её можно найти).
После ввода PGP-PRIV-KEY, уже в своём терминале - получатель может расшифровать зашифрованную чипом отправителя инфу,
и тогда уже, его терминал, может записать её на такой же аналогичный чип - выдав получателю ту же купюру.
7. Инфа на чипе старой купюры - зануляется, а купюра отправителя - пожирается терминалом.
На неё, же, терминал может писать инфу для других получателей, делая с неё другие купюры.
Но тут, на этапе расшифровки - терминал может скопировать privkey.
И чтобы этого не было, он может залить сразу шифр в купюру, а активировать её для валидации,
можно было бы, введя свой секретный PGP-privkey при помощи специального устройства,
подключаемого к чипу купюры.
Тогда, PGP-privkey - поступает на вход чипа, с последующей дешифровкой чипом шифра - в инфу получателя,
и записью в этот чип изначального privkey.
Однако, не забываем о том, что сами транзы - засирают блокчейн гигабайтами.
Если privkey не выдавать из чипа, а только подписывать транзакции ним, то очевидно наличие транзакций в сети bitcoin.
А вот с чипо-купюрами, с фиксированным номиналом, можно было бы и попроще...
Без транзакций, как с фиатом.
Сначала, купюра пожирается, инфа на чипе считывается, летит получателю в другой терминал, а ему вылазит такая же ровно - купюра,
затем инфа на чипе первой купюры - сбрасывается и она стаёт невалидной. Всё.
Так как privkey не знает ни владелец, ни получатель, он - один не меняется, является одним и тем же privkey,
но эта схема уязвима к перехвату этого privkey - терминалом, с последующим сливом c адреса купюры - биткоинового обеспечения.
В таком случае, купюра уже не пройдёт валидацию.
И хотя эта схема вообще без транзакций, как у фиата,
это пиздатый баг. Она может открывать дыру хакерам - для массовых скамов и сливов...
И чтобы чип не палил privkey - терминалу, очевидно, что можно было бы его шифровать асимметрично!
Например, при помощи PGP: https://username1565.github.io/pgp/
1. Получатель - генерирует пару ключей PGP, и держит в секрете свой PGP privkey.
2. Отправитель (владелец чипо-купюры), просит его подписать ним - некое проверочное сообщение.
3. Получатель подписывает privkey'eм сообщение, и отправляет его, вместе с PUB-key - отправителю.
4. Отправитель - вводит в терминал PGP-pubkey получателя, и проверяет цифровую подпись получателя,
тем самым - он убеждается, что приватный ключ PGP - имеется у получателя, а цифровая подпись - корректна.
5. При переводе монет получателю, отправитель пишет в терминале - просто его PGP-PUB-key,
причём - однократно, при проверке сообщения,
и этот PGP-PUB-key - он вводит, как адрес получателя.
6. Из терминала отправителя, этот PGP-PUB-key получателя - поступает уже на вход ЧИПА-купюры,
после чего, ЧИП ШИФРУЕТ инфу внутри себя - асимметрично, этим PGP-PUB-KEY, и выдаёт терминалу - шифр.
Терминал не знает саму инфу, и просто шлёт получателю криптоинфу, или заводит её в терминальную базу,
вместе с PUB-key получателя (по которому её можно найти).
После ввода PGP-PRIV-KEY, уже в своём терминале - получатель может расшифровать зашифрованную чипом отправителя инфу,
и тогда уже, его терминал, может записать её на такой же аналогичный чип - выдав получателю ту же купюру.
7. Инфа на чипе старой купюры - зануляется, а купюра отправителя - пожирается терминалом.
На неё, же, терминал может писать инфу для других получателей, делая с неё другие купюры.
Но тут, на этапе расшифровки - терминал может скопировать privkey.
И чтобы этого не было, он может залить сразу шифр в купюру, а активировать её для валидации,
можно было бы, введя свой секретный PGP-privkey при помощи специального устройства,
подключаемого к чипу купюры.
Тогда, PGP-privkey - поступает на вход чипа, с последующей дешифровкой чипом шифра - в инфу получателя,
и записью в этот чип изначального privkey.
>>429741
Но как быть с дубликатом чип-карты? Как гарантировать, что производитель его не выпустит?
Но как быть с дубликатом чип-карты? Как гарантировать, что производитель его не выпустит?
>>429740
Прочитал тут твой поток сознания, но так и не понял, ты хочешь освободить блокчейн от транзакций, притом обмениваться битком?
Слова Lightning Network тебе что-то говорят?
Я не понимаю, зачем изобретать бумажный велосипед, если он уже придуман.
Прочитал тут твой поток сознания, но так и не понял, ты хочешь освободить блокчейн от транзакций, притом обмениваться битком?
Слова Lightning Network тебе что-то говорят?
Я не понимаю, зачем изобретать бумажный велосипед, если он уже придуман.
>>393621 (OP)
Полюбому хуйня протроянена бажными, легковскрываемыми алгоритмами, которые на первый взгляд не видно из исходников. То что нету обмена данными, ни о чем не говорит, сгенеренные этой парашей кошельки можно будет позже вскрыть по зашифрованной туда создателем методе.
Полюбому хуйня протроянена бажными, легковскрываемыми алгоритмами, которые на первый взгляд не видно из исходников. То что нету обмена данными, ни о чем не говорит, сгенеренные этой парашей кошельки можно будет позже вскрыть по зашифрованной туда создателем методе.
>>432887
Лал, исходник открыт. Все функции - прозрачны, и имеют вполне читабельный код.
Если видишь чё-то, что кажется тебе "подозрительным",
то укажи строку, например вот так:
https://github.com/username1565/MultiCoin-paperwallet/blob/bf9e36c94093972e90b98a719bb6abbef0d6003c/index_files/COINS_ARRAY.js#L70
Там спецом генератор рандома вшит, который работает локально,
а рандом зависит от хэша положения курсора мыши.
И да, его код же - тоже открыт.
Лал, исходник открыт. Все функции - прозрачны, и имеют вполне читабельный код.
Если видишь чё-то, что кажется тебе "подозрительным",
то укажи строку, например вот так:
https://github.com/username1565/MultiCoin-paperwallet/blob/bf9e36c94093972e90b98a719bb6abbef0d6003c/index_files/COINS_ARRAY.js#L70
Там спецом генератор рандома вшит, который работает локально,
а рандом зависит от хэша положения курсора мыши.
И да, его код же - тоже открыт.
![20120207-124546-268[1].jpg](https://2ch.hk//cc/src/393621/15606124004590.jpg)
>>432021
Очевидно, что карты, изначально - должны быть болванками,
а прошивать карту надо локально, через специальное портативное устройство.
На первых двух картинках - запись данных на магнитные карты.
На двух других - карты с чипом.
Так как предлагаются к использованию карты с чипами - то чип должен иметь возможность
шифровать-дешифровать данные сам,
а также - не отдавать данные какому-либо карт-ридеру - в сыром виде, а только в виде шифра.
Крипта же, ёпт.
>Но как быть с дубликатом чип-карты? Как гарантировать, что производитель его не выпустит?
Очевидно, что карты, изначально - должны быть болванками,
а прошивать карту надо локально, через специальное портативное устройство.
На первых двух картинках - запись данных на магнитные карты.
На двух других - карты с чипом.
Так как предлагаются к использованию карты с чипами - то чип должен иметь возможность
шифровать-дешифровать данные сам,
а также - не отдавать данные какому-либо карт-ридеру - в сыром виде, а только в виде шифра.
Крипта же, ёпт.
>>432062
Да.
Интересная технология, но больше похожи на контаркты bitmex'a, то есть это скорее права на биткоин,
а не сам биткоин. Ведь биткоин хранится в каналах, а они могут отключиться или заскамить юзера.
Вообще-то, как я уже написал выше, обычный paperwallet может представлять из себя реальный бумажный биткоин.
Таким образом - биткоин может заменить фиат и даже вытеснить его.
Но, недостаток такого подхода в том, что приватный ключ может быть скопирован, а сам биткоин - слит.
Это то же самое, что по номеру купюры, в банке, с твоего счёта кто-то может забрать золотое обеспечение бумажных денег, и тогда фиатные фантики останутся без реального покрытия - то есть обычной макулатурой.
>>432021
И всё-же, этот пост >>432944 - не отвечает на выше заданный вопрос...
Ведь локально можно было бы прошить на болванках - две одинаковые чип-карты.
Решить эту траблу мог бы тот факт, что на болванки, изначально, записывается шифр PGP.
А затем уже, локально - производится активация карты, владельцем секретного ключа PGP,
с последующей расшифровкой PGP-шифра внутри чипа, и записью сырых данных - на чип.
В дополнение ко всему этому - в карте может содержаться также ещё и хардварно-прошитый серийный номер карты.
Смотри:
Боб, как получатель биткоинов - получает из банкомата карту с биткоинами.
Это - болванка. На ней уже вписан - шифр PGP, содержащий зашифрованное состояние предыдущей,
уже неактивной - карты Алисы. Алиса - перевела Бобу биткоины, её карта сожрана терминалом.
Карта - теперь у Боба. Он её получает, и активирует локально, подавая на вход чипа - закрытый ключ PGP.
Этим ключём - расшифровывается PGP-шифр, и на чип карты - пишутся сырые данные карты Алисы.
Всё, биткоины у Боба. То есть, у Боба - та же карта Алисы,
с тем же PRIV, на чипе, в карте, с тем же адресом, и биткоинами на адресе,
но карта эта - с другим серийным номером карты.
Дальше, представим следующую ситуацию:
Есть Боб, с картой, с определённым серийным номером,
и как законный владелец биткоинов Алисы - на ней данные Алисы (priv, address, и биткоины на адресе).
И внезапно, появляется некая Кэрол, с такой же картой, там, на чипе - данные Алисы, но у карты - другой серийный номер.
Такой юзер мог бы получится либо в случае, если Боб уже перевёл биткоины Кэрол, либо если Кэрол - хакер,
записавший перехваченный шифр PGP на чип карты-болванки.
Но тогда, даже при таком раскладе, без PGP_PRIVATE_KEY Боба,
Кэрол не могла бы расшифровать этот PGP-шифр, и восстановить на чипе карты данные Алисы.
Только Боб может активировать такую карту.
Но, допустим, у неё получилось каким-то невъебенным образом,
узнать сам PRIVKEY Алисы, содержащийся на чипе карты Боба, и прописать его в сыром виде на чип своей карты.
Кто в таком случае законный владелец биткоинов? Очевидно, что Кэрол, ведь у неё PRIV.
Она может также - сделать транзу и в биткоиновом блокчейне.
Однако, Верификатор, при обнаружении двух одинаковых карт с разными серийными номерами
- сразу же банит обе карты, и Боба, и Алисы, пожирает их,
а взамен них - выдаёт обоим юзерам карты, содержащие на чипе PGP-шифр,
зашифрованный PGP-PUBLIC-ключём, последнего законного владельца.
Очевидно, что активировать такую карту локально - сможет тот, кто владеет приватным ключём PGP, то есть Боб.
И если Кэрол тупо сдампила ёбанный PRIV Алисы, и прошила их на чип карты как hexadecimal values,
и не являясь при этом - хакером, является обычным тупым, уёбищным кардером,
то нихуя она не получит, никакие битки,
а из терминала вылетит пиздатая боксёрская перчатка на жесткой пружине, и залетит ей прямо в ебло,
при следующей вставке её инвалидной придурошной карты, блядь.
А Бобу, при активации карты, должно быть выдано уведомление о том, что следует сменить PRIV,
ведь карта эта выдана в результате аннуляции двух карт, и пока ещё PRIV содержится в виде hex'a - у Кэрол,
она может тупо - увести битки по блокчейну.
Технически, это предупреждение может быть зашифровано дополнительным текстом,
шифруемым PGP-ключём Боба, с последующей записью шифра на чип карты.
Сама Кэрол может при этом - ничего не подозревать, увидем галочку валидации карты,
при проверке её фейко-карты.
>ты хочешь освободить блокчейн от транзакций, притом обмениваться битком?
Да.
>Слова Lightning Network тебе что-то говорят?
Интересная технология, но больше похожи на контаркты bitmex'a, то есть это скорее права на биткоин,
а не сам биткоин. Ведь биткоин хранится в каналах, а они могут отключиться или заскамить юзера.
>Я не понимаю, зачем изобретать бумажный велосипед, если он уже придуман.
Вообще-то, как я уже написал выше, обычный paperwallet может представлять из себя реальный бумажный биткоин.
Таким образом - биткоин может заменить фиат и даже вытеснить его.
Но, недостаток такого подхода в том, что приватный ключ может быть скопирован, а сам биткоин - слит.
Это то же самое, что по номеру купюры, в банке, с твоего счёта кто-то может забрать золотое обеспечение бумажных денег, и тогда фиатные фантики останутся без реального покрытия - то есть обычной макулатурой.
>>432021
>Но как быть с дубликатом чип-карты? Как гарантировать, что производитель его не выпустит?
И всё-же, этот пост >>432944 - не отвечает на выше заданный вопрос...
Ведь локально можно было бы прошить на болванках - две одинаковые чип-карты.
Решить эту траблу мог бы тот факт, что на болванки, изначально, записывается шифр PGP.
А затем уже, локально - производится активация карты, владельцем секретного ключа PGP,
с последующей расшифровкой PGP-шифра внутри чипа, и записью сырых данных - на чип.
В дополнение ко всему этому - в карте может содержаться также ещё и хардварно-прошитый серийный номер карты.
Смотри:
Боб, как получатель биткоинов - получает из банкомата карту с биткоинами.
Это - болванка. На ней уже вписан - шифр PGP, содержащий зашифрованное состояние предыдущей,
уже неактивной - карты Алисы. Алиса - перевела Бобу биткоины, её карта сожрана терминалом.
Карта - теперь у Боба. Он её получает, и активирует локально, подавая на вход чипа - закрытый ключ PGP.
Этим ключём - расшифровывается PGP-шифр, и на чип карты - пишутся сырые данные карты Алисы.
Всё, биткоины у Боба. То есть, у Боба - та же карта Алисы,
с тем же PRIV, на чипе, в карте, с тем же адресом, и биткоинами на адресе,
но карта эта - с другим серийным номером карты.
Дальше, представим следующую ситуацию:
Есть Боб, с картой, с определённым серийным номером,
и как законный владелец биткоинов Алисы - на ней данные Алисы (priv, address, и биткоины на адресе).
И внезапно, появляется некая Кэрол, с такой же картой, там, на чипе - данные Алисы, но у карты - другой серийный номер.
Такой юзер мог бы получится либо в случае, если Боб уже перевёл биткоины Кэрол, либо если Кэрол - хакер,
записавший перехваченный шифр PGP на чип карты-болванки.
Но тогда, даже при таком раскладе, без PGP_PRIVATE_KEY Боба,
Кэрол не могла бы расшифровать этот PGP-шифр, и восстановить на чипе карты данные Алисы.
Только Боб может активировать такую карту.
Но, допустим, у неё получилось каким-то невъебенным образом,
узнать сам PRIVKEY Алисы, содержащийся на чипе карты Боба, и прописать его в сыром виде на чип своей карты.
Кто в таком случае законный владелец биткоинов? Очевидно, что Кэрол, ведь у неё PRIV.
Она может также - сделать транзу и в биткоиновом блокчейне.
Однако, Верификатор, при обнаружении двух одинаковых карт с разными серийными номерами
- сразу же банит обе карты, и Боба, и Алисы, пожирает их,
а взамен них - выдаёт обоим юзерам карты, содержащие на чипе PGP-шифр,
зашифрованный PGP-PUBLIC-ключём, последнего законного владельца.
Очевидно, что активировать такую карту локально - сможет тот, кто владеет приватным ключём PGP, то есть Боб.
И если Кэрол тупо сдампила ёбанный PRIV Алисы, и прошила их на чип карты как hexadecimal values,
и не являясь при этом - хакером, является обычным тупым, уёбищным кардером,
то нихуя она не получит, никакие битки,
а из терминала вылетит пиздатая боксёрская перчатка на жесткой пружине, и залетит ей прямо в ебло,
при следующей вставке её инвалидной придурошной карты, блядь.
А Бобу, при активации карты, должно быть выдано уведомление о том, что следует сменить PRIV,
ведь карта эта выдана в результате аннуляции двух карт, и пока ещё PRIV содержится в виде hex'a - у Кэрол,
она может тупо - увести битки по блокчейну.
Технически, это предупреждение может быть зашифровано дополнительным текстом,
шифруемым PGP-ключём Боба, с последующей записью шифра на чип карты.
Сама Кэрол может при этом - ничего не подозревать, увидем галочку валидации карты,
при проверке её фейко-карты.
>>432062
Да.
Интересная технология, но больше похожи на контаркты bitmex'a, то есть это скорее права на биткоин,
а не сам биткоин. Ведь биткоин хранится в каналах, а они могут отключиться или заскамить юзера.
Вообще-то, как я уже написал выше, обычный paperwallet может представлять из себя реальный бумажный биткоин.
Таким образом - биткоин может заменить фиат и даже вытеснить его.
Но, недостаток такого подхода в том, что приватный ключ может быть скопирован, а сам биткоин - слит.
Это то же самое, что по номеру купюры, в банке, с твоего счёта кто-то может забрать золотое обеспечение бумажных денег, и тогда фиатные фантики останутся без реального покрытия - то есть обычной макулатурой.
>>432021
И всё-же, этот пост >>432944 - не отвечает на выше заданный вопрос...
Ведь локально можно было бы прошить на болванках - две одинаковые чип-карты.
Решить эту траблу мог бы тот факт, что на болванки, изначально, записывается шифр PGP.
А затем уже, локально - производится активация карты, владельцем секретного ключа PGP,
с последующей расшифровкой PGP-шифра внутри чипа, и записью сырых данных - на чип.
В дополнение ко всему этому - в карте может содержаться также ещё и хардварно-прошитый серийный номер карты.
Смотри:
Боб, как получатель биткоинов - получает из банкомата карту с биткоинами.
Это - болванка. На ней уже вписан - шифр PGP, содержащий зашифрованное состояние предыдущей,
уже неактивной - карты Алисы. Алиса - перевела Бобу биткоины, её карта сожрана терминалом.
Карта - теперь у Боба. Он её получает, и активирует локально, подавая на вход чипа - закрытый ключ PGP.
Этим ключём - расшифровывается PGP-шифр, и на чип карты - пишутся сырые данные карты Алисы.
Всё, биткоины у Боба. То есть, у Боба - та же карта Алисы,
с тем же PRIV, на чипе, в карте, с тем же адресом, и биткоинами на адресе,
но карта эта - с другим серийным номером карты.
Дальше, представим следующую ситуацию:
Есть Боб, с картой, с определённым серийным номером,
и как законный владелец биткоинов Алисы - на ней данные Алисы (priv, address, и биткоины на адресе).
И внезапно, появляется некая Кэрол, с такой же картой, там, на чипе - данные Алисы, но у карты - другой серийный номер.
Такой юзер мог бы получится либо в случае, если Боб уже перевёл биткоины Кэрол, либо если Кэрол - хакер,
записавший перехваченный шифр PGP на чип карты-болванки.
Но тогда, даже при таком раскладе, без PGP_PRIVATE_KEY Боба,
Кэрол не могла бы расшифровать этот PGP-шифр, и восстановить на чипе карты данные Алисы.
Только Боб может активировать такую карту.
Но, допустим, у неё получилось каким-то невъебенным образом,
узнать сам PRIVKEY Алисы, содержащийся на чипе карты Боба, и прописать его в сыром виде на чип своей карты.
Кто в таком случае законный владелец биткоинов? Очевидно, что Кэрол, ведь у неё PRIV.
Она может также - сделать транзу и в биткоиновом блокчейне.
Однако, Верификатор, при обнаружении двух одинаковых карт с разными серийными номерами
- сразу же банит обе карты, и Боба, и Алисы, пожирает их,
а взамен них - выдаёт обоим юзерам карты, содержащие на чипе PGP-шифр,
зашифрованный PGP-PUBLIC-ключём, последнего законного владельца.
Очевидно, что активировать такую карту локально - сможет тот, кто владеет приватным ключём PGP, то есть Боб.
И если Кэрол тупо сдампила ёбанный PRIV Алисы, и прошила их на чип карты как hexadecimal values,
и не являясь при этом - хакером, является обычным тупым, уёбищным кардером,
то нихуя она не получит, никакие битки,
а из терминала вылетит пиздатая боксёрская перчатка на жесткой пружине, и залетит ей прямо в ебло,
при следующей вставке её инвалидной придурошной карты, блядь.
А Бобу, при активации карты, должно быть выдано уведомление о том, что следует сменить PRIV,
ведь карта эта выдана в результате аннуляции двух карт, и пока ещё PRIV содержится в виде hex'a - у Кэрол,
она может тупо - увести битки по блокчейну.
Технически, это предупреждение может быть зашифровано дополнительным текстом,
шифруемым PGP-ключём Боба, с последующей записью шифра на чип карты.
Сама Кэрол может при этом - ничего не подозревать, увидем галочку валидации карты,
при проверке её фейко-карты.
>ты хочешь освободить блокчейн от транзакций, притом обмениваться битком?
Да.
>Слова Lightning Network тебе что-то говорят?
Интересная технология, но больше похожи на контаркты bitmex'a, то есть это скорее права на биткоин,
а не сам биткоин. Ведь биткоин хранится в каналах, а они могут отключиться или заскамить юзера.
>Я не понимаю, зачем изобретать бумажный велосипед, если он уже придуман.
Вообще-то, как я уже написал выше, обычный paperwallet может представлять из себя реальный бумажный биткоин.
Таким образом - биткоин может заменить фиат и даже вытеснить его.
Но, недостаток такого подхода в том, что приватный ключ может быть скопирован, а сам биткоин - слит.
Это то же самое, что по номеру купюры, в банке, с твоего счёта кто-то может забрать золотое обеспечение бумажных денег, и тогда фиатные фантики останутся без реального покрытия - то есть обычной макулатурой.
>>432021
>Но как быть с дубликатом чип-карты? Как гарантировать, что производитель его не выпустит?
И всё-же, этот пост >>432944 - не отвечает на выше заданный вопрос...
Ведь локально можно было бы прошить на болванках - две одинаковые чип-карты.
Решить эту траблу мог бы тот факт, что на болванки, изначально, записывается шифр PGP.
А затем уже, локально - производится активация карты, владельцем секретного ключа PGP,
с последующей расшифровкой PGP-шифра внутри чипа, и записью сырых данных - на чип.
В дополнение ко всему этому - в карте может содержаться также ещё и хардварно-прошитый серийный номер карты.
Смотри:
Боб, как получатель биткоинов - получает из банкомата карту с биткоинами.
Это - болванка. На ней уже вписан - шифр PGP, содержащий зашифрованное состояние предыдущей,
уже неактивной - карты Алисы. Алиса - перевела Бобу биткоины, её карта сожрана терминалом.
Карта - теперь у Боба. Он её получает, и активирует локально, подавая на вход чипа - закрытый ключ PGP.
Этим ключём - расшифровывается PGP-шифр, и на чип карты - пишутся сырые данные карты Алисы.
Всё, биткоины у Боба. То есть, у Боба - та же карта Алисы,
с тем же PRIV, на чипе, в карте, с тем же адресом, и биткоинами на адресе,
но карта эта - с другим серийным номером карты.
Дальше, представим следующую ситуацию:
Есть Боб, с картой, с определённым серийным номером,
и как законный владелец биткоинов Алисы - на ней данные Алисы (priv, address, и биткоины на адресе).
И внезапно, появляется некая Кэрол, с такой же картой, там, на чипе - данные Алисы, но у карты - другой серийный номер.
Такой юзер мог бы получится либо в случае, если Боб уже перевёл биткоины Кэрол, либо если Кэрол - хакер,
записавший перехваченный шифр PGP на чип карты-болванки.
Но тогда, даже при таком раскладе, без PGP_PRIVATE_KEY Боба,
Кэрол не могла бы расшифровать этот PGP-шифр, и восстановить на чипе карты данные Алисы.
Только Боб может активировать такую карту.
Но, допустим, у неё получилось каким-то невъебенным образом,
узнать сам PRIVKEY Алисы, содержащийся на чипе карты Боба, и прописать его в сыром виде на чип своей карты.
Кто в таком случае законный владелец биткоинов? Очевидно, что Кэрол, ведь у неё PRIV.
Она может также - сделать транзу и в биткоиновом блокчейне.
Однако, Верификатор, при обнаружении двух одинаковых карт с разными серийными номерами
- сразу же банит обе карты, и Боба, и Алисы, пожирает их,
а взамен них - выдаёт обоим юзерам карты, содержащие на чипе PGP-шифр,
зашифрованный PGP-PUBLIC-ключём, последнего законного владельца.
Очевидно, что активировать такую карту локально - сможет тот, кто владеет приватным ключём PGP, то есть Боб.
И если Кэрол тупо сдампила ёбанный PRIV Алисы, и прошила их на чип карты как hexadecimal values,
и не являясь при этом - хакером, является обычным тупым, уёбищным кардером,
то нихуя она не получит, никакие битки,
а из терминала вылетит пиздатая боксёрская перчатка на жесткой пружине, и залетит ей прямо в ебло,
при следующей вставке её инвалидной придурошной карты, блядь.
А Бобу, при активации карты, должно быть выдано уведомление о том, что следует сменить PRIV,
ведь карта эта выдана в результате аннуляции двух карт, и пока ещё PRIV содержится в виде hex'a - у Кэрол,
она может тупо - увести битки по блокчейну.
Технически, это предупреждение может быть зашифровано дополнительным текстом,
шифруемым PGP-ключём Боба, с последующей записью шифра на чип карты.
Сама Кэрол может при этом - ничего не подозревать, увидем галочку валидации карты,
при проверке её фейко-карты.
>>432953
Верификатор может "банить" (перевыпускать) - обе карты, и Боба и Кэрол.
Сама же Карта Алисы - уже аннулирована и сожрана терминалом, при переводе битков Бобу.
при проверке её фейко-карты.
Это уже другой вариант, беспалевный, то есть Кэрол, потенциально зная PRIV от адреса битка,
временно пользуется фейко-картой ничего не подозревая,
но при этом, Бобу даётся возможность сменить этот PRIV,
и это - просто потому, что его PGP-PUB в базе верификаторов -
является последим PUB'ом законного владельца,
а Кэрол - прошила карту без транзакции в сети верификаторов.
Да, может быть такое, очень редкий случай.
Допустим, Кэрол сгенерировала PRIV, получила адрес,
проверила в блокчейне баланс, а там битки, лол.
И не зная что делать с этим - тупо записала priv на карту и пошла с нею - шопить.
И при таком раскладе - законным владельцем битков, всё-равно является Боб,
ибо у него транзы по терминалам, были верифицированы.
Поэтому, Бобу карта могла бы перевыпускаться сразу,
тогда, в один момент, все транзакции Кэрол - могут быть заорфанены.
>Однако, Верификатор, при обнаружении двух одинаковых карт с разными серийными номерами -
>сразу же банит обе карты, и Боба, и Алисы, пожирает их
Верификатор может "банить" (перевыпускать) - обе карты, и Боба и Кэрол.
Сама же Карта Алисы - уже аннулирована и сожрана терминалом, при переводе битков Бобу.
>Сама Кэрол может при этом - ничего не подозревать, увидем галочку валидации карты,
при проверке её фейко-карты.
Это уже другой вариант, беспалевный, то есть Кэрол, потенциально зная PRIV от адреса битка,
временно пользуется фейко-картой ничего не подозревая,
но при этом, Бобу даётся возможность сменить этот PRIV,
и это - просто потому, что его PGP-PUB в базе верификаторов -
является последим PUB'ом законного владельца,
а Кэрол - прошила карту без транзакции в сети верификаторов.
Да, может быть такое, очень редкий случай.
Допустим, Кэрол сгенерировала PRIV, получила адрес,
проверила в блокчейне баланс, а там битки, лол.
И не зная что делать с этим - тупо записала priv на карту и пошла с нею - шопить.
И при таком раскладе - законным владельцем битков, всё-равно является Боб,
ибо у него транзы по терминалам, были верифицированы.
Поэтому, Бобу карта могла бы перевыпускаться сразу,
тогда, в один момент, все транзакции Кэрол - могут быть заорфанены.
>>432953
Таким образом - биткоин может заменить фиат и даже вытеснить его.
Но, недостаток такого подхода в том, что приватный ключ может быть скопирован, а сам биткоин - слит.
эээээ ... ну это... косяки восприятия же ... не упирайся мозгом в бумажные деньги) - он имеет в виду то что больше похоже на чековую книжку, напечатал с утра себе на мелкие расходы вай нот? только такой чек который хуй кто подделает это лучше чем бумажные деньги так-то
>Вообще-то, как я уже написал выше, обычный paperwallet может представлять из себя реальный бумажный биткоин.
Таким образом - биткоин может заменить фиат и даже вытеснить его.
Но, недостаток такого подхода в том, что приватный ключ может быть скопирован, а сам биткоин - слит.
эээээ ... ну это... косяки восприятия же ... не упирайся мозгом в бумажные деньги) - он имеет в виду то что больше похоже на чековую книжку, напечатал с утра себе на мелкие расходы вай нот? только такой чек который хуй кто подделает это лучше чем бумажные деньги так-то
>>393621 (OP)
Аноны, есть ли где-то сорцы мультикриптовалютных веб-кошельков,
в которых можно только проверить баланс и перевести крипту?
Что-то наподобие вот этого: https://guarda.co/ только с открытым сорцом,
а не проприетарное и копирастическое какое-то © , ®, TM, с закрытым кодом.
Хочу поднять у себя подобную шнягу, и возможно даже сервер с блокчейнами, но для рандомного альта.
Веб кошельки радуют тем, что с их помощью - можно втюхать любую крипту,
рандомному челу с баблом, не знающему о конкретной крипте - от слова совсем.
Например, продать биток по 20к, взять у него бабло, перечислить ему битки, чтобы он его получил,
а потом сказать что биток упал до рыночной цены. И купить их же, но дешевле. Лол.
Так можно пампить монеты, кстати, такими вот холдерами.
Главное, чтобы в веб-кошельке был только баланс крипты, а не эквивалентная рыночной стоимости сумма.
Ведь хомяк может вообще не знать о рынке, и о биржах, его может интересовать только крипта.
Короче, палите годноту опенсорцную, вроде этого вот мультикошеля https://guarda.co/
Аноны, есть ли где-то сорцы мультикриптовалютных веб-кошельков,
в которых можно только проверить баланс и перевести крипту?
Что-то наподобие вот этого: https://guarda.co/ только с открытым сорцом,
а не проприетарное и копирастическое какое-то © , ®, TM, с закрытым кодом.
Хочу поднять у себя подобную шнягу, и возможно даже сервер с блокчейнами, но для рандомного альта.
Веб кошельки радуют тем, что с их помощью - можно втюхать любую крипту,
рандомному челу с баблом, не знающему о конкретной крипте - от слова совсем.
Например, продать биток по 20к, взять у него бабло, перечислить ему битки, чтобы он его получил,
а потом сказать что биток упал до рыночной цены. И купить их же, но дешевле. Лол.
Так можно пампить монеты, кстати, такими вот холдерами.
Главное, чтобы в веб-кошельке был только баланс крипты, а не эквивалентная рыночной стоимости сумма.
Ведь хомяк может вообще не знать о рынке, и о биржах, его может интересовать только крипта.
Короче, палите годноту опенсорцную, вроде этого вот мультикошеля https://guarda.co/
Оп, ты еще тут?
Внедри поддержку вот этой штуки в свою программулину.
https://gitlab.com/NebulousLabs/sia-coldstorage
Внедри поддержку вот этой штуки в свою программулину.
https://gitlab.com/NebulousLabs/sia-coldstorage
>>449820
Да, я тут мимопроходил.
Это что? SiaCoin что-ли? https://coinmarketcap.com/currencies/siacoin/#markets
Или форк его? Они там не загнулись ещё со своей много-десятко-миллирдной эмиссией?
Что это ты закинул тут? Какие-то файлы на Go-Lang. Это всё что на JS переписывать?
Знал бы ты как я ебался с подключением эфира.
Мало того что алго какой-то неведомый надо впиливать,
так ещё и принцип генерации у них немного другой.
Там, вроде сид буквенный выдаётся, и пачка адресов потом.
Поэтому, вот, нашёл тебе, пока, вот такой генератор: https://github.com/roccstar/sia-coldstorage-json
Демо - вот тут: https://mysiacoin.com (покликай на логотип для перегенерации).
Этот paperwallet, как я понял, работает client-side, если слить его в zip, и открыть wallet.html.
Но тогда, без дизайна будет просто страничка с данными.
Как видно в исходнике wallet.html, весь генератор - находится в файле sia-coldstorage-json.min.js,
который нечитабелен, потому что это минифицированный файл.
Зато он инклюдится одной строкой с папки рядом, и весь паперваллет работает локально, без Интернета
Я думаю этого тебе будет достаточно.
Да, я тут мимопроходил.
Это что? SiaCoin что-ли? https://coinmarketcap.com/currencies/siacoin/#markets
Или форк его? Они там не загнулись ещё со своей много-десятко-миллирдной эмиссией?
Что это ты закинул тут? Какие-то файлы на Go-Lang. Это всё что на JS переписывать?
Знал бы ты как я ебался с подключением эфира.
Мало того что алго какой-то неведомый надо впиливать,
так ещё и принцип генерации у них немного другой.
Там, вроде сид буквенный выдаётся, и пачка адресов потом.
Поэтому, вот, нашёл тебе, пока, вот такой генератор: https://github.com/roccstar/sia-coldstorage-json
Демо - вот тут: https://mysiacoin.com (покликай на логотип для перегенерации).
Этот paperwallet, как я понял, работает client-side, если слить его в zip, и открыть wallet.html.
Но тогда, без дизайна будет просто страничка с данными.
Как видно в исходнике wallet.html, весь генератор - находится в файле sia-coldstorage-json.min.js,
который нечитабелен, потому что это минифицированный файл.
Зато он инклюдится одной строкой с папки рядом, и весь паперваллет работает локально, без Интернета
Я думаю этого тебе будет достаточно.
>>450104
Если надо, я гошный скомпилирую.
Мы ведь оба знаем, что это совсем не проблема.
This. И поэтому, я так полагаю, в твою штуку оно не подойдет.
Эмиссия и правда большая, кушать хорошо разработчики хотят. Но, я считаю, это один из лучших блокчейн прожектов за последнее время.
> Поэтому, вот, нашёл тебе, пока, вот такой генератор:
Если надо, я гошный скомпилирую.
> sia-coldstorage-json.min.js,
> который нечитабелен, потому что это минифицированный файл
Мы ведь оба знаем, что это совсем не проблема.
> сид буквенный выдаётся
This. И поэтому, я так полагаю, в твою штуку оно не подойдет.
> Они там не загнулись ещё со своей много-десятко-миллирдной эмиссией?
Эмиссия и правда большая, кушать хорошо разработчики хотят. Но, я считаю, это один из лучших блокчейн прожектов за последнее время.
>>450104
Добавлю. Прожект пилится, подвозят новые фичи, шара растёт, 3-rd party потихоньку пилят софт.
> Они там не загнулись ещё со своей много-десятко-миллирдной эмиссией?
Добавлю. Прожект пилится, подвозят новые фичи, шара растёт, 3-rd party потихоньку пилят софт.
>>393621 (OP)
А давайте запилим p2p-мессенджеры децентрализированные, вроде bitmessage, но - с эллиптической криптографией?
Здесь: https://github.com/username1565/mini_ecdsa/blob/master/tests_ECC.py ,
вы можете найти пример кода,
для кодирования и декодирования сообщений - точками на эллиптической кривой, в конечном поле,
а также последующего шифрования этих точек, умножением и делением точек на эллиптической кривой.
username1565
А давайте запилим p2p-мессенджеры децентрализированные, вроде bitmessage, но - с эллиптической криптографией?
Здесь: https://github.com/username1565/mini_ecdsa/blob/master/tests_ECC.py ,
вы можете найти пример кода,
для кодирования и декодирования сообщений - точками на эллиптической кривой, в конечном поле,
а также последующего шифрования этих точек, умножением и делением точек на эллиптической кривой.
username1565
>>456927
Есть уже p2p мессенжеры на блокчейне. Про кривую не знаю. Смотрел-крутил. Один совсем в зачаточном состоянии, другой вроде ничего, но стэк у него большно помойный (жаваскрипт там и прочее говео). Но фичи туда постеменно подвозят. Но разработчики неадекваты. Меня кикнули и забанили в их чате через 5 минут общения, хотя я всего лишь общие вопросы задавал, хоть и с подколками. ADM - погугли, если интересно. А вобще идея хорошая, я бы вписался, но программирую плохо. А ты на чем писать предлагаешь?
Есть уже p2p мессенжеры на блокчейне. Про кривую не знаю. Смотрел-крутил. Один совсем в зачаточном состоянии, другой вроде ничего, но стэк у него большно помойный (жаваскрипт там и прочее говео). Но фичи туда постеменно подвозят. Но разработчики неадекваты. Меня кикнули и забанили в их чате через 5 минут общения, хотя я всего лишь общие вопросы задавал, хоть и с подколками. ADM - погугли, если интересно. А вобще идея хорошая, я бы вписался, но программирую плохо. А ты на чем писать предлагаешь?
>>457161
Вот: https://coinmarketcap.com/ru/currencies/adamant-messenger/
Ну а что ты хочешь? Они шиткоин для распродажи напремайнили себе, вот и вербуют лохов в чатике.
Ты что думаешь там технари сидят?
Если чо - надо сам исходник открытый смотреть, внутрь кода: https://github.com/adamant-im
а не к пиар-менеджерам в чатики идти,
но мне чё-то лениво код смотреть,
и сдаётся мне, что вся сердцевина - обфусцирована там копирастически
и замкнута на какую-то корпорацию разведчиков с этой ихней - слежкой.
Не знаю. Я даже не представляю себе как именно должен работать мессенджер, но примерно чую, что как TOX
(без ввода телефонов и эмейлов, и с локальной генерацией ключей).
Тот код, на питоне, я вам просто закинул, чтобы вы поколупали его сами,
он вроде как шифрует и дешифровывает нормально по эллиптической кривой.
Так что можете покрутить повертеть его, в смысле - как математики,
оценить криптостойкость там, и может чё-нить более криптовое запилите.
Так-то, как видишь, там, реализовано закодированных-декодированных в точки - сообщений,
и осуществляется шифрование-дешифрование - умножением-делением этих точек - на приватный ключ (число),
а на выходе - получаются совсем другие точки на кривой.
Но если одно и то же число использовать в качестве ключа,
то, ИМХО, частотный анализ длинных сообщений, возможно, может помочь его вскрыть (сам ключ).
А может и нет...
Вот представь себе. Ты знаешь сообщение (точку), и знаешь шифротекст (другую точку). Разделил одну на другую, и получил ключ - как-то так нет, лол, ECDLP же.
Но чё-то стрёмно один ключ юзать, и я, думаю, что следовало бы на базе ключа - PRNG какой-то сделать из точек,
в большом кольце этом, на эллиптической кривой,
и оттуда уже извлекать всякие другие числа (те же координаты точек, например),
которые уже потом, и использовать как динамические ключи шифрования.
Вот тогда было бы годно, не?
Это было бы что-то вроде абсолютно-криптостойкого шифра Вернама, и главное - портативное.
Один ключ подал на вход, изначально, затем помножил генераторную точку на него. Получил другую точку.
Её удвоил - получил совсем третью точку. Где она - хрен знает, но это зависит от ключа.
Её потом удвоил - четвёртая точка. И так далее, хоть миллиард их. Кривая превращается в PRNG,
значения которого ещё и обратимы. Ведь деление на два можно двигать псевдослучайную последовательность точек - вправо-влево.
Так вот, длинная последовательность точек этих, может быть как ключ шифра Вернама.
А дальше уже - перекриптовать всё это, вычислить хэш, подписать его и отправить.
>ADM - погугли, если интересно.
Вот: https://coinmarketcap.com/ru/currencies/adamant-messenger/
>Меня кикнули и забанили в их чате через 5 минут общения
Ну а что ты хочешь? Они шиткоин для распродажи напремайнили себе, вот и вербуют лохов в чатике.
Ты что думаешь там технари сидят?
Если чо - надо сам исходник открытый смотреть, внутрь кода: https://github.com/adamant-im
а не к пиар-менеджерам в чатики идти,
но мне чё-то лениво код смотреть,
и сдаётся мне, что вся сердцевина - обфусцирована там копирастически
и замкнута на какую-то корпорацию разведчиков с этой ихней - слежкой.
>А вобще идея хорошая, я бы вписался, но программирую плохо. А ты на чем писать предлагаешь?
Не знаю. Я даже не представляю себе как именно должен работать мессенджер, но примерно чую, что как TOX
(без ввода телефонов и эмейлов, и с локальной генерацией ключей).
Тот код, на питоне, я вам просто закинул, чтобы вы поколупали его сами,
он вроде как шифрует и дешифровывает нормально по эллиптической кривой.
Так что можете покрутить повертеть его, в смысле - как математики,
оценить криптостойкость там, и может чё-нить более криптовое запилите.
Так-то, как видишь, там, реализовано закодированных-декодированных в точки - сообщений,
и осуществляется шифрование-дешифрование - умножением-делением этих точек - на приватный ключ (число),
а на выходе - получаются совсем другие точки на кривой.
Но если одно и то же число использовать в качестве ключа,
то, ИМХО, частотный анализ длинных сообщений, возможно, может помочь его вскрыть (сам ключ).
А может и нет...
Вот представь себе. Ты знаешь сообщение (точку), и знаешь шифротекст (другую точку). Разделил одну на другую, и получил ключ - как-то так нет, лол, ECDLP же.
Но чё-то стрёмно один ключ юзать, и я, думаю, что следовало бы на базе ключа - PRNG какой-то сделать из точек,
в большом кольце этом, на эллиптической кривой,
и оттуда уже извлекать всякие другие числа (те же координаты точек, например),
которые уже потом, и использовать как динамические ключи шифрования.
Вот тогда было бы годно, не?
Это было бы что-то вроде абсолютно-криптостойкого шифра Вернама, и главное - портативное.
Один ключ подал на вход, изначально, затем помножил генераторную точку на него. Получил другую точку.
Её удвоил - получил совсем третью точку. Где она - хрен знает, но это зависит от ключа.
Её потом удвоил - четвёртая точка. И так далее, хоть миллиард их. Кривая превращается в PRNG,
значения которого ещё и обратимы. Ведь деление на два можно двигать псевдослучайную последовательность точек - вправо-влево.
Так вот, длинная последовательность точек этих, может быть как ключ шифра Вернама.
А дальше уже - перекриптовать всё это, вычислить хэш, подписать его и отправить.
>>457161
Вот: https://coinmarketcap.com/ru/currencies/adamant-messenger/
Ну а что ты хочешь? Они шиткоин для распродажи напремайнили себе, вот и вербуют лохов в чатике.
Ты что думаешь там технари сидят?
Если чо - надо сам исходник открытый смотреть, внутрь кода: https://github.com/adamant-im
а не к пиар-менеджерам в чатики идти,
но мне чё-то лениво код смотреть,
и сдаётся мне, что вся сердцевина - обфусцирована там копирастически
и замкнута на какую-то корпорацию разведчиков с этой ихней - слежкой.
Не знаю. Я даже не представляю себе как именно должен работать мессенджер, но примерно чую, что как TOX
(без ввода телефонов и эмейлов, и с локальной генерацией ключей).
Тот код, на питоне, я вам просто закинул, чтобы вы поколупали его сами,
он вроде как шифрует и дешифровывает нормально по эллиптической кривой.
Так что можете покрутить повертеть его, в смысле - как математики,
оценить криптостойкость там, и может чё-нить более криптовое запилите.
Так-то, как видишь, там, реализовано закодированных-декодированных в точки - сообщений,
и осуществляется шифрование-дешифрование - умножением-делением этих точек - на приватный ключ (число),
а на выходе - получаются совсем другие точки на кривой.
Но если одно и то же число использовать в качестве ключа,
то, ИМХО, частотный анализ длинных сообщений, возможно, может помочь его вскрыть (сам ключ).
А может и нет...
Вот представь себе. Ты знаешь сообщение (точку), и знаешь шифротекст (другую точку). Разделил одну на другую, и получил ключ - как-то так нет, лол, ECDLP же.
Но чё-то стрёмно один ключ юзать, и я, думаю, что следовало бы на базе ключа - PRNG какой-то сделать из точек,
в большом кольце этом, на эллиптической кривой,
и оттуда уже извлекать всякие другие числа (те же координаты точек, например),
которые уже потом, и использовать как динамические ключи шифрования.
Вот тогда было бы годно, не?
Это было бы что-то вроде абсолютно-криптостойкого шифра Вернама, и главное - портативное.
Один ключ подал на вход, изначально, затем помножил генераторную точку на него. Получил другую точку.
Её удвоил - получил совсем третью точку. Где она - хрен знает, но это зависит от ключа.
Её потом удвоил - четвёртая точка. И так далее, хоть миллиард их. Кривая превращается в PRNG,
значения которого ещё и обратимы. Ведь деление на два можно двигать псевдослучайную последовательность точек - вправо-влево.
Так вот, длинная последовательность точек этих, может быть как ключ шифра Вернама.
А дальше уже - перекриптовать всё это, вычислить хэш, подписать его и отправить.
>ADM - погугли, если интересно.
Вот: https://coinmarketcap.com/ru/currencies/adamant-messenger/
>Меня кикнули и забанили в их чате через 5 минут общения
Ну а что ты хочешь? Они шиткоин для распродажи напремайнили себе, вот и вербуют лохов в чатике.
Ты что думаешь там технари сидят?
Если чо - надо сам исходник открытый смотреть, внутрь кода: https://github.com/adamant-im
а не к пиар-менеджерам в чатики идти,
но мне чё-то лениво код смотреть,
и сдаётся мне, что вся сердцевина - обфусцирована там копирастически
и замкнута на какую-то корпорацию разведчиков с этой ихней - слежкой.
>А вобще идея хорошая, я бы вписался, но программирую плохо. А ты на чем писать предлагаешь?
Не знаю. Я даже не представляю себе как именно должен работать мессенджер, но примерно чую, что как TOX
(без ввода телефонов и эмейлов, и с локальной генерацией ключей).
Тот код, на питоне, я вам просто закинул, чтобы вы поколупали его сами,
он вроде как шифрует и дешифровывает нормально по эллиптической кривой.
Так что можете покрутить повертеть его, в смысле - как математики,
оценить криптостойкость там, и может чё-нить более криптовое запилите.
Так-то, как видишь, там, реализовано закодированных-декодированных в точки - сообщений,
и осуществляется шифрование-дешифрование - умножением-делением этих точек - на приватный ключ (число),
а на выходе - получаются совсем другие точки на кривой.
Но если одно и то же число использовать в качестве ключа,
то, ИМХО, частотный анализ длинных сообщений, возможно, может помочь его вскрыть (сам ключ).
А может и нет...
Вот представь себе. Ты знаешь сообщение (точку), и знаешь шифротекст (другую точку). Разделил одну на другую, и получил ключ - как-то так нет, лол, ECDLP же.
Но чё-то стрёмно один ключ юзать, и я, думаю, что следовало бы на базе ключа - PRNG какой-то сделать из точек,
в большом кольце этом, на эллиптической кривой,
и оттуда уже извлекать всякие другие числа (те же координаты точек, например),
которые уже потом, и использовать как динамические ключи шифрования.
Вот тогда было бы годно, не?
Это было бы что-то вроде абсолютно-криптостойкого шифра Вернама, и главное - портативное.
Один ключ подал на вход, изначально, затем помножил генераторную точку на него. Получил другую точку.
Её удвоил - получил совсем третью точку. Где она - хрен знает, но это зависит от ключа.
Её потом удвоил - четвёртая точка. И так далее, хоть миллиард их. Кривая превращается в PRNG,
значения которого ещё и обратимы. Ведь деление на два можно двигать псевдослучайную последовательность точек - вправо-влево.
Так вот, длинная последовательность точек этих, может быть как ключ шифра Вернама.
А дальше уже - перекриптовать всё это, вычислить хэш, подписать его и отправить.
>>393621 (OP)
Пока вы тут хуйнёй страдаете, тут такое знаменательное событие произошло!
Репост с архивача: https://arhivach.ng/thread/538151/#1618710
ООООО?!! Да это же неубиваемая, принципиально немочерируемая, и легко-поднимаемая в TOR'e - НАНОБОРДА!
Пока вы тут хуйнёй страдаете, тут такое знаменательное событие произошло!
>>2743161
Репост с архивача: https://arhivach.ng/thread/538151/#1618710
>Раз в 4 года можно увидеть не только 29 февраля,
>но ОХУЕННОЕ ОБНОВЛЕНИЕ - НАНОБОРДЫ!
>
>Встречайте Nanoboard 3.3,
>с lite-server'ом для расшаривания
>и возможностью включения постинга без каптчи!
ООООО?!! Да это же неубиваемая, принципиально немочерируемая, и легко-поднимаемая в TOR'e - НАНОБОРДА!
Тред утонул или удален.
Это копия, сохраненная 1 марта 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 1 марта 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.