Запускаем IQUIDUS

Запускаем IQUIDUS

В основнов всё тоже самое, что и в этих гайдах:
https://www.reddit.com/r/BiblePay/comments/7elm7r/iquidus_block_explorer_guide/
https://gist.github.com/zeronug/5c66207c426a1d4d5c73cc872255c572
https://github.com/iquidus/explorer1. Устанавливаем TTChttps://ss-iqrw.blogspot.ru/2018/01/ttc-08-ubuntu.html
(не забываем про безопасность – везде используем свои пароли)2. Устанавливаем MongoDBhttps://docs.mongodb.com/manual/tutorial/install-mongodb-on-ubuntu/sudo apt-key adv –keyserver hkp://keyserver.ubuntu.com:80 –recv 2930ADAE8CAF5059EE73BB4B58712A2291FA4AD5


echo “deb [ arch=amd64,arm64 ] https://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.6 multiverse” | sudo tee /etc/apt/sources.list.d/mongodb-org-3.6.list


sudo apt-get update


sudo apt-get install -y mongodb-org


sudo service mongod start

2. Создаём базу данных MongoDB

mongo

use explorerdb

db.createUser( { user: “TTC”, pwd: “RWcq7y*3*Xq!H^8”, roles: [ “readWrite” ] } )

exit

3. Устанавливаем Node.js

sudo apt-get update

sudo apt-get install nodejs nodejs-legacy -y

sudo apt-get install npm

4. Клонируем блокэксплорер IQUIDUS в Домашнюю папку (Home)

git clone https://github.com/iquidus/explorer explorer

cd explorer && npm install –production

cp ./settings.json.template ./settings.json

Если появятся такие ошибки – https://github.com/nodejs/node-gyp/issues/809
sudo apt-get install libkrb5-dev

5. Редактируем конфигурационный файл settings.json

“coin”: “TTcoin”,

“symbol”: “TTC”,

“dbsettings”: {
“user”: “TTC”,
“password”: “RWcq7y*3*Xq!H^8”,
“database”: “explorerdb”,
“address”: “localhost”,
“port”: 27017
},

“wallet”: {
“host”: “localhost”,
“port”: 17510,
“user”: “ttcoinrpc”,
“pass”: “3JNQ7cJ6LB4UqsSgsr4KZTfW55vcLLGmGUGQptUjRMX1”
},

“api”: {
“blockindex”: 5972,
“blockhash”: “000000216a1f9406461adef5296dfb81f83262d06ccd1cc3a49c4b79f662184d”,
“txhash”: “834d65d55bb109b43414b9924d071a47d830fb308f7941c4fa08be17fcc251ce”,
“address”: “TGW9x4XvQvgJZL1MBTJR3RgverWijTCg7D”
},

“genesis_tx”: “6fe8289b644faf01b5abadde67a0855cb81ecb9d08b8805874fa9f7ad232c075”,
“genesis_block”: “00000009efba3f88db6f03373c7ff6f6be1b6f9ad21306b4eb26f65dfdffac8d”,

“labels”: {
“TVVVjcdyVJF67hSXMg7aDGbHsx7mGoJgz7”: {“label”: “neiros”, “type”:”primary”, “url”:”https://bitcointalk.org/index.php?topic=2254304.0″},
“TYw4sTfrcA5Bk8nh5Rx2bwTTSqDPgKZUqK”: {“label”: “Developers address”, “type”:”primary”, “url”:”http://ss-iqr.blogspot.ru/2017/09/ttc.html”},
},

6. Запуск IQUIDUS

В каталоге explorer выполняем команду
npm start

С этого момента можно открыть браузер и на локальном компьютере по этому адресу http://127.0.0.1:3001/ должен заработать IQUIDUS

При начальном запуске в другой консоли выполняем
sudo node scripts/sync.js index update
или
sudo node scripts/sync.js index reindex

7. Добавляем задания в Crontab

sudo crontab -e

При первом запуске выбираем для Crontab редактор nano. По умолчанию он под номером 2.
Записываем эти две строчки:

*/1 * * * * cd /path/to/explorer && /usr/bin/nodejs scripts/sync.js index update > /dev/null 2>&1
*/5 * * * * cd /path/to/explorer && /usr/bin/nodejs scripts/peers.js > /dev/null 2>&1

Где /path/to место нахождения каталога explorer(узнать можно, например /home/neiros, правой кнопкой мыши в свойствах или командой pwd)

8. Для последующих запусков

sudo service mongod start

cd ttc/src && ./ttcoind

cd ../../explorer && npm start

Остановка работы блокэксплорера – сочетание клавиш Ctrl + С (остановка TTC – cd ../ttc/src && ./ttcoind stop)

Если перестанет обновляться список транзакций в браузере, следует удалить файл index.pid в каталоге tmp

rm tmp/index.pid

Безконсольная работа: forever start bin/cluster

Для этого нужно установить:
sudo npm install forever -g
sudo npm install forever-monitor


IQUIDUS долго индексирует транзакции блокчейна, что не очень подходит для больших объёмов


Что бы блокэксплорер показывал комиссии транзакций нужно немного подправить эти файлы:

lib/database.js


var inTotal = 0;
function save_tx(txid, cb) {

update_address(nvin[i].addresses, txid, nvin[i].amount, ‘vin’, function(){
inTotal += nvin[i].amount;
loop.next();
});

lib.calculate_total(vout, function(total){
var f = 0;
                    if (inTotal){
                      f = inTotal – total;
                    }
var newTx = new Tx({
txid: tx.txid,
vin: nvin,
vout: vout,
total: total.toFixed(8),
timestamp: tx.time,
blockhash: tx.blockhash,
blockindex: block.height,
fee: f.toFixed(8)
});
inTotal = 0;
newTx.save(function(err) {

models/tx.js


var TxSchema = new Schema({
txid: { type: String, lowercase: true, unique: true, index: true},
vin: { type: Array, default: [] },
vout: { type: Array, default: [] },
total: { type: Number, default: 0 },
timestamp: { type: Number, default: 0 },
blockhash: { type: String },
blockindex: {type: Number, default: 0},
fee: {type: Number, default: 0}
}, {id: false});

views/tx.jade


.col-md-6
.panel.panel-default
.panel-heading
– var txFee = tx.fee / 100000000
strong #{settings.locale.tx_recipients} (fee: #{txFee.toFixed(8)})
table.table.table-bordered.table-striped.summary-table


 

Iquidus Block Explorer Guide

 

Pre-requisites:

  • Rent Server

  • Connect with SSH/PuTTY


==
Iquidus
“An open source block explorer”
https://github.com/iquidus/explorer

==

Node and Iquidus Explorer Setup for Dummies
https://gist.github.com/zeronug/5c66207c426a1d4d5c73cc872255c572

==

1. Install & Configure BiblePay https://www.reddit.com/r/BiblePay/comments/6ummuj/how_to_mine_biblepay_on_linux/

After Installing the coin, Add RPC & Server settings:

vi biblepay.conf

rpcuser=XXXX
rpcpassword=XXXX
rpcport=XXXX
listen=1
server=1
daemon=1
txindex=1

==
2. Install MongoDB
https://docs.mongodb.com/manual/tutorial/install-mongodb-on-ubuntu/

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 0C49F3730359A14518585931BC711F9BA15703C6

echo "deb [ arch=amd64,arm64 ] http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.4.list

sudo apt-get update

sudo apt-get install -y mongodb-org

sudo service mongod start

cd /var/log/mongodb
tail mongod.log
# [initandlisten] waiting for connections on port <port>
# Port 27017 by default

3. Setup MongoDB

mongo
use explorerdb
db.createUser( { user: "iquidus", pwd: "3xp!0reR", roles: [ "readWrite" ] } )
exit

4. Install Node.js

sudo apt-get update
sudo apt-get install nodejs nodejs-legacy -y
sudo apt-get install npm

5. Install Iquidis Block Explorer

cd home/username
git clone https://github.com/iquidus/explorer explorer

# gyp build errors
# https://github.com/nodejs/node-gyp/issues/809
sudo apt-get install libkrb5-dev

cd explorer && npm install --production

cp ./settings.json.template ./settings.json

6. Configure Iquidis

vi settings.json

a. Name, Symbol, Theme

b. Port (and Open for Firewall)

c. MongoDB Credentials

d. RPC Wallet Credentials

e. Genesis Block (showblock 0, hash=block, tx=tx)
https://en.bitcoin.it/wiki/Genesis_block

f. CCEX Market
https://support.coinigy.com/hc/en-us/articles/360001143574-How-do-I-find-my-API-key-on-the-C-Cex-Exchange-

e. Icon and Logo
/images/logo.png 128×128
/public/favicon.ico 16×16
Upload files online and use “wget URL” command to download
http://digitalagencyrankings.com/iconogen/


7. Sync Initial Database

cd home/username/biblepay/src  
./biblepayd -daemon -txindex  

cd home/username/explorer
npm start

Open a 2nd SSH/Putty session and connect, in 2nd window run:

cd home/username/explorer
sudo node scripts/sync.js index update 

Open web browser and enter in your servers address: IPAddress:Port


8. Troubleshooting

Ctrl + C to stop npm process

__

If Settings/Config is wrong:
Edit explorer/settings.json

__

If Database is corrupt:

mongo  
use explorerdb  
show collections  

Examples: db.collectionName.find()
db.collectionName.remove({}) db.collectionName.drop()

Reset all Database Data:

db.addresses.remove({})
db.addresses.drop()
db.coinstats.remove({})
db.coinstats.drop()
db.markets.remove({})
db.markets.drop()
db.peers.remove({})
db.peers.drop()
db.richlists.remove({})
db.richlists.drop()
db.txes.remove({})
db.txes.drop()
exit

__

“Trying to reindex and getting error Script already running”
https://github.com/iquidus/explorer/issues/11

rm tmp/index.pid  

__

Stop Everything:

sudo service mongod stop
sudo killall nodejs
#Comment out crontab -e

__

Run npm start in explorer folder to start explorer again


9. Add Crontab and Run!

sudo crontab -e

Add lines:

*/1 * * * * cd /path/to/explorer && /usr/bin/nodejs scripts/sync.js index update > /dev/null 2>&1  
*/2 * * * * cd /path/to/explorer && /usr/bin/nodejs scripts/sync.js market > /dev/null 2>&1  
*/5 * * * * cd /path/to/explorer && /usr/bin/nodejs scripts/peers.js > /dev/null 2>&1  

If the BiblePay isnt already running, run it

cd home/username/biblepay/src  
./biblepayd -daemon -txindex  

If Explorer isnt already running, run it

cd home/username/explorer
npm start

Recommendation:*

Add these parameters to biblepay.conf file

daemon=1
txindex=1

Extra:
This Iquidis for Dummides guide also adds:
https://gist.github.com/zeronug/5c66207c426a1d4d5c73cc872255c572

Upstart, to have MongoDB auto start after reboots

Forever, to make sure Explorer is always running

Install Forever to keep the js running
# sudo npm install forever -g
# sudo npm install forever-monitor

Start the Explorer
# forever start bin/cluster

Nginx – Reverse Proxy Port 3001 to 80
https://eladnava.com/binding-nodejs-port-80-using-nginx/


BiblePay Daemon set to run Every 2 Minutes with Cron

sudo crontab -e  
*/2 * * * * /home/biblepay/src/biblepayd > /dev/null 2>&1  

Note: In ~/.biblepaycore/biblepay.conf add daemon=1 and txindex=1
Note: > /dev/null 2>&1 will capture both STDOUT (1) and STDERR (2) and send them to /dev/null


Auto Remove index.pid if indexing is complete

#!/bin/bash
fname="/home/biblepay/explorer/tmp/index.pid"
if [[ -f "$fname" ]];
then
        pid=$(</home/biblepay/explorer/tmp/index.pid)
        echo $pid
        ps -p $pid > /dev/null
        r=$?
        echo $r
        if [ $r -eq 0 ]; then
                exit 1
        else
                rm $fname
        fi
fi

-f is checking if the file exists
index.pid is the indexing lock file with its process ID number inside of it
ps -p checks if the process is running
$? is the value of the last output that ran and since the previous value is going to dev/null, its the exit code status
“0 for successful executions and 1 or higher for failed executions.”
and so if the process is still running, the bash script just exits, otherwise the process is done and the index.pid file gets removed
the file doesnt need a .sh extension, if you have “#!/bin/bash” at the top then linux knows its a bash script chmod +x to set it as executable


Github Source Code Files:

https://github.com/togoshigekata/biblepay-files/blob/master/explorer-settings-togo.json

https://github.com/togoshigekata/biblepay-files/blob/master/explorer-index-resetter-togo.sh


My Crontab:

*/2 * * * * cd /home/explorer && /usr/bin/nodejs --stack-size=15000 scripts/sync.js index update > /dev/null 2>&1
*/6 * * * * cd /home/explorer && /usr/bin/nodejs scripts/sync.js market > /dev/null 2>&1
*/11 * * * * cd /home/explorer && /usr/bin/nodejs scripts/peers.js > /dev/null 2>&1

*/5 * * * * /home/biblepay/src/biblepayd > /dev/null 2>&1
*/4 * * * * /home/explorer-index-resetter-togo.sh > /dev/null 2>&1
0 */3 * * * /usr/sbin/service mongod start > /dev/null 2>&1

Experimental:
https://github.com/iquidus/explorer/issues/236

Атаки «Поддельной ставки» основанные на блокчейне криптовалюты Proof-of-Stake

Эта статья является публичным раскрытием серии уязвимостей, связанных с исчерпанием ресурсов, которые исследовала группа студентов, состоящая из Санкета Канджалкара ( sanket1729 , smk7@illinois.edu ), Юньци Ли, Югуан Чен, Джозеф Куо и нашего советника Эндрю Миллера ( socrates1024 ) в Лаборатории децентрализованных систем @ UIUC. Эти уязвимости затронули в общей сложности более 26 криптовалют Proof-of-Stake и позволили сетевому злоумышленнику с очень небольшим количеством ставок прервать работу любого из узлов сети, на которых работает соответствующее программное обеспечение. Мы начали скоординированное раскрытие информации в октябре 2018 года, чтобы уведомить группы разработчиков об уязвимых криптовалютах перед этим публичным выпуском. Большинство из них (взвешенных по рыночному капиталу) уже развернули меры по смягчению.

Криптовалюты Proof-of-Stake (PoS), особенно те, которые основаны на PoSv3 на основе цепочки ( Proof-of-Stake версия 3 ), аналогичны биткойнам в том, что они используют модель UTXO и правила консенсуса с самой длинной цепью. Ключевое отличие состоит в том, что они заменяют Proof-of-Work на подтверждение владения монетами. Потенциальные преимущества подхода PoS варьируются от снижения воздействия на окружающую среду до повышения безопасности против 51% атак. Многие криптовалюты на самом деле являются ветвями (или, по крайней мере, потомками) кодовой базы Биткойна, с привитой функциональностью PoS. Однако некоторые идеи проекта небезопасно копируются, что приводит к новым уязвимостям, которых не было в родительской кодовой базе.

Мы называем найденные уязвимости «поддельными ставками». По сути, они работают, потому что реализации PoSv3 не проводят адекватную проверку сетевых данных перед выделением ценных ресурсов (диск и ОЗУ). Следствием этого является то, что злоумышленник без особой заинтересованности (а в некоторых случаях и вовсе) может вызвать сбой узла-жертвы, заполнив его диск или ОЗУ фиктивными данными. Мы считаем, что все валюты, основанные на модели UTXO и самой длинной цепочке Proof-of-Stake, уязвимы для этих атак «поддельного кола». Список криптовалют, которые мы исследовали и полагаем, были затронуты, показан в конце статьи.

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

Фон:

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

Доказательство добычи:

Как и при майнинге Proof-of-Work, майнинг в PoS состоит из сравнения хеша заголовка блока с целью сложности. Цель PoS высокого уровня состоит в том, чтобы гарантировать, что шансы каждого участника на майнинг следующего блока пропорциональны количеству монет, которые они контролируют. Для этого в PoS на основе цепочки хэш зависит не только от заголовка блока, но и от количества монет, включенных в специальную транзакцию «получения монет», вставленную заинтересованным лицом в блок. Точные детали PoS майнинга могут быть немного сложными, и подробное объяснение можно найти в блоге Earlz. Для этого поста важно то, что проверка PoS зависит от 1) транзакции получения монеты и 2) UTXO, потраченной транзакцией получения монеты.

Роль Proof-of-Work в защите ресурсов проверки блоков:

Хорошо известно, что Proof-of-Work (PoW) играет важную роль в достижении биткойн-консенсуса. Но Proof-of-Work также играет вторую, несколько менее значимую роль, которая защищает доступ к ограниченным ресурсам узла, таким как диск, полоса пропускания, память и процессор. В криптовалютной сети без прав доступа одноранговым узлам нельзя доверять. Таким образом, для предотвращения атак исчерпания ресурсов узлы Биткойн сначала проверяют PoW на наличие принятых блоков, прежде чем выделять больше ресурсов, таких как хранение блока в ОЗУ или на диске. Однако оказывается, что проверка Proof-of-Stake намного сложнее и контекстно-зависима, чем проверка Proof-of-Work. В результате многие реализации PoS на основе цепочек экономили на соответствующей проверке.

Чтобы понять, как это приводит к уязвимости, связанной с исчерпанием ресурсов, мы должны немного рассказать о том, как блоки хранятся перед проверкой. Узел должен не только отслеживать самую длинную цепочку в текущий момент времени, но также и дерево цепочек вилок (любая из них может оказаться самой длинной цепью, и в этом случае узел должен «перезапустить», чтобы переключиться на него ). Это может произойти, например, во время неудачного обновления, атаки с двойным расходом (атака ETC до 51% ) или временного сетевого раздела.

Проверка этих блоков вне основной цепи затруднена. Для полной проверки блока вам понадобится набор неизрасходованных монет (UTXO) во время предыдущего блока. Биткойн сохраняет UTXO для текущей вершины лучшей цепочки, но не для всех других прошлых блоков, с которых может начаться форк. Существует два основных подхода для полной проверки блоков на вилке:

  1. «Откатить» текущий вид (установлен UTXO) до точки перед началом форка, или
  2. хранить копии набора UTXO для всех предыдущих блоков.

Кодовая база Биткойна не поддерживает Вариант 2, и даже если бы он это сделал, это привело бы к дополнительным затратам на хранение (производительность узла Биткойн зависит от агрессивного удаления ненужных данных). Вариант 1 – это именно то, как база данных биткойнов в настоящее время обрабатывает реорг. Однако это может быть очень дорого, поэтому откат и полная проверка отложены до последнего возможного момента, когда Proof-of-Work в форке уже больше, чем текущая основная цепь. Таким образом, вместо того, чтобы одноранговый узел впервые получил блок или заголовок, который не является частью самой длинной цепочки, полная проверка пропускается, и блок сохраняется в локальном хранилище.

Перед сохранением блока на диск кодовая база Биткойн выполняет некоторую предварительную проверку на основе PoW (но игнорирует транзакции). Эта предварительная проверка зависит только от предыдущего заголовка блока и текущего заголовка, поэтому узел может сделать это очень быстро. И это эффективная защита, потому что генерация действительного PoW, который его проходит, очень дорогая. Например, хотя можно обмануть узел Биткойн, чтобы он хранил недопустимый блок на диске, монтировать атаку на исчерпание ресурсов таким способом непозволительно дорого.

Аналогичная предварительная проверка в PoS заключается в проверке транзакции с монетой и проверке того, что она проходит цель сложности при хешировании с ядром предыдущего блока. Вычисление хэша транзакции получения монеты легко, но сложная часть – проверка, является ли входной UTXO для транзакции получения монеты действительным и неизрасходованным, поскольку для этого требуется проверка набора UTXO, который, как упоминалось ранее, недоступен для предыдущих блоков. Поскольку полная проверка транзакции с монетой сложна, большинство реализаций PoS на основе цепочки вместо этого предоставляют эвристическую или приблизительную проверку. Оказывается, что эти приближения часто неадекватны и могут быть использованы.

Уязвимость № 1: «Я не могу поверить, что это не кол»

Когда мы впервые исследовали эту проблему, мы обнаружили, что пять криптовалют, Qtum, Particl, Navcoin, HTMLcoin и Emercoin, продемонстрировали довольно тривиальную форму этой уязвимости: а именно, они вообще не проверяют какую-либо монетную транзакцию перед фиксацией блока в ОЗУ или диск. Общим для этих пяти криптовалют является то, что они приняли функцию биткойнов «сначала заголовки», в которой распространение блоков было разделено на два отдельных сообщения: блок и заголовок. Узлы запрашивают блокировку только после того, как заголовок прошел проверку PoW И это самая длинная (или длинная) цепочка. Поскольку транзакция сбора монет присутствует только в блоке, но не в заголовке, узел не может самостоятельно проверить заголовок. Вместо этого он непосредственно сохраняет заголовок в структуре данных в памяти (mapBlockIndex). В результате любой сетевой злоумышленник, даже не имея никакой ставки, может заполнить ОЗУ узла-жертвы.

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

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

Эксплуатация любой из этих уязвимостей может быть осуществлена ​​без участия в криптовалюте. Версия атаки в ОЗУ особенно тривиальна, но по техническим причинам дисковая версия атаки требует немного большей осторожности ( хотя все равно никакой ставки не требуется) . Детали объяснены в коротком документе, который будет представлен на Финансовой Криптографии 2019 .

Уязвимость # 2 и атака на потраченный кол

Прослеживая происхождение этих кодовых баз, мы заметили, что уязвимость # 1 была первоначально введена при объединении функции Bitcoin «header-first» в кодовую базу PoSv3. Атака не работает на более ранних версиях (например, Peercoin), поскольку перед сохранением блоков на диске есть две дополнительные предварительные проверки:

  1. Проверьте, существует ли расходуемый выход в главной цепи.
  2. Проверьте, соответствует ли хеш ядра PoS цели сложности.

Проверка 1 выполняется путем поиска в базе данных транзакций (TxDB), которая пока отслеживает все транзакции в текущей основной цепочке. Другими словами, предварительная проверка лучше, чем отсутствие проверки, но все же эвристическое и неполное приближение полной проверки. Если вы придерживаетесь объяснения до этого момента, две проблемы могут возникнуть прямо на вас:

Проблема А : Проверка 1 гарантирует, что монета существует, но НЕ, что она не потрачена. Это понимание сразу же приводит к уязвимости, которую мы обсудим далее.

Проблема B : Даже если мы проверяем блок на развилке основной цепочки, транзакция состязания проверяется по TxDB для самой главной цепочки.

Основываясь на проблеме А, мы также нашли способ обмануть эти проверки, используя более тонкую атаку, которую мы называем « атака с использованием кола ». Чтобы обойти проверку 1, мы используем вывод, который виден узлом, но уже потрачен , Как правило, чтобы обойти Проверка 2, нам нужно было бы добыть действительный блок, который проходит цель сложности, которая в свою очередь потребовала бы большого количества ставки. Однако, как выясняется, мы можем злоупотреблять неполной проверкой, чтобы генерировать произвольное количество видимой ставки, используя технику, которую мы называем « усиление ставки ».

Усиление кола

Чтобы выполнить атаку, начиная с небольшого количества ставок, атакующий должен увеличить их количество кажущейся ставки. Под очевидной ставкой понимаются итоговые результаты ставок кандидатов, даже те, которые уже потрачены. Если злоумышленник начинает с UTXO суммы k, то злоумышленник может создать несколько транзакций, тратя монеты обратно злоумышленнику, как показано на рисунке ниже. Для размещения может быть разрешено только UTXO (n + 1 ), но благодаря проверке 2, приведенной выше, мы можем делать ставки со всеми UTXO от 1 до n + 1 , увеличивая тем самым кажущуюся ставку на n * k . Это увеличивает шансы найти блок PoS, так как злоумышленник может продолжать делать это, чтобы увеличить свою очевидную ставку. Это показано как « шаг амплификации кола » на левой стороне иллюстрации ниже.

Усиление ставки и атака потраченной ставки

Например, даже имея 0,01% акций в системе, злоумышленнику требуется только 5000 транзакций для майнинга блоков с 50% очевидной мощности пакета. После того, как злоумышленник собрал большое количество видимых ставок, он затем приступил к добыче блоков PoS в прошлом, используя недавно собранные выходные данные очевидных ставок. Наконец, злоумышленник заполняет диск равноправного узла недействительными блоками, как показано в правой части иллюстрации выше. Злоумышленник может, например, купить несколько монет на бирже, увеличить ставку за счет собственных расходов, как мы описали, а затем продать эти монеты обратно на биржу, выполнив атаку в любой более поздний срок. Злоумышленнику придется заплатить только за транзакции.

Скоординированное раскрытие уязвимостей

Сначала мы исследовали уязвимость # 1 в контексте криптовалют Particl и Qtum. Чтобы определить степень этой уязвимости, мы собрали список известных криптовалют с сайта coinmarketcap.com (9 августа 2018 г.), отсортированный по рыночной капитализации, и фильтруется по согласованному типу PoS. Мы смотрели только на криптовалюты, чья кодовая база была разветвлена ​​от (потомка) биткойна, то есть в C ++. В общей сложности мы исследовали 26 криптовалют и обнаружили, что были затронуты только пять криптовалют (Qtum, Navcoin, HTMLcoin, Emercoin и Particl), но наша атака, похоже, не сработала на остальных. Чтобы подтвердить уязвимость, мы реализовали атаки в каждой из пяти затронутых кодовых баз. Мы использовали существующие тестовые наборы в программном обеспечении Биткойн, в частности режим regtest , который позволяет имитировать временные метки и легко создаваемые блоки, и тестовый узел на основе Python (на основе биткойна TestFramework ), который можно расширять с помощью поведения злоумышленника. Мы использовали контейнеры Docker для упаковки этих тестов, их зависимостей и конкретного хэша фиксации, включенного в набор для воспроизводимости, который мы могли бы легко поделиться со всеми пятью затронутыми группами разработчиков в рамках нашего раскрытия уязвимости.

Затем мы углубились, чтобы понять, почему незатронутые криптовалюты не были подвержены первой атаке, и поняли, что уязвимость № 2 была почти такой же серьезной (требующей минимального количества пакетов), но гораздо более распространенной. При планировании скоординированного ответственного раскрытия мы считали, что раскрытие криптовалютам с низкой экономической активностью и неактивными командами разработчиков может оказаться контрпродуктивным (например, существует риск того, что, если уязвимость будет обнаружена, она может повлиять на других, прежде чем они время для развертывания смягчения). В конечном итоге мы решили сфокусировать наше внимание на общении с пятнадцатью командами разработчиков, связанными с криптовалютами, которые наиболее вероятно подвергнутся атаке (среди 200 лучших криптовалют) и будут отзывчивыми (некоторые совершают действия в течение 2018 года).

Одним из усложняющих факторов является то, что большинство этих кодовых баз не имели режима регестрации, поэтому мы не могли легко продемонстрировать атаку или предоставить набор воспроизводимости для каждого из них. Поэтому мы только продемонстрировали кодовую базу C ++ stratisX. Основываясь на сходстве кодовых баз, мы сообщили всем пятнадцати командам, что, по нашему мнению, это повлияет. Пять групп признали эту уязвимость, три все еще проводят расследование, три опровергли ее (указали на изменения в реализации, которые оказали смягчающее воздействие), а четыре группы не дали ответа. Для четырех команд, которые не ответили, мы связались с ними по каналам, которые мы могли найти на их веб-сайтах. ⁶ Наш комплект по воспроизведению Github для обеих уязвимостей можно найти здесь, а наш краткий документ об уязвимости # 1 можно найти здесь . Мы также зарезервировали CVE для уязвимостей, которые скоро должны быть опубликованы.

Данные Marketcap за 9 августа 2018 года: coinmarketcap.com

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

В некоторых других криптовалютах добавлена ​​частичная проверка вплоть до фиксированной длины. Er Если одноранговый узел получает блок, который разветвляется из главной цепи после этой длины, то блок просто отбрасывается. Этот подход также используется, например, в кодовой базе ABC BCH (Bitcoin Cash), в которой используется скользящая контрольная точка из 10 блоков. Недостаток этого подхода заключается в том, что он вводит возможность «разделения цепей». Разделение цепей происходит, когда честные узлы оказываются на разных расходящихся ветвях блокчейна. Это может произойти, например, если плохое сетевое соединение приводит к тому, что узлы не синхронизируются друг с другом в течение достаточно длительного времени для создания конфликтующих контрольных точек. Даже если узлы восстановят соединение, они не смогут достичь общего представления о цепочке. Мы отмечаем, что риск разделения цепей присутствует даже без этого снижения. Вспоминая озабоченность B из более ранней версии, поскольку транзакция сбора монет проверяется с использованием выходных данных транзакции в текущей цепочке, возможно, что узел не сможет переключиться на фактическую основную цепочку, если он временно окажется на вилке.

Риск разделения цепей также вводит новые векторы атаки для враждебных майнеров. Злоумышленник может попытаться секретно добыть длинную цепочку, а затем опубликовать ее в подмножестве узлов, чтобы вызвать разрыв цепочки. Узлы в IBD (Initial Block Download) или узлы, которые только что перезапустились после длительного периода автономной работы, особенно уязвимы для этой атаки. Такие атаки могут сочетаться с атаками затмения, чтобы привести честные узлы в цепочку, контролируемую атакующим.

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

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

В приведенной ниже таблице указаны валюты, которые, по нашему мнению, подвержены одной из двух описанных выше уязвимостей. Мы еще не проверили уязвимости для всех валют, и мы еще не изучили, почему валюты, которые опровергли наши требования, не были затронуты.

Последние мысли

Хотя атаки по принципу «поддельной ставки» в принципе просты, они подчеркивают сложную задачу проектирования: некоторые идеи, имеющие смысл в Proof-of-Work, не передаются надежно в Proof-of-Stake. Учитывая высокую степень совместного использования кода Bitcoin Core как «восходящего потока» среди криптовалюты PoSv3, мы считаем, что это заслуживает еще большей проверки. При исследовании этих уязвимостей мы обнаружили несколько примеров в различных кодовых базах незавершенного производства (или закомментированного кода), которые направлены на различные меры по снижению риска и специальные защиты. Для нас это говорит о том, что разработчики PoS осознают, что компромиссы и требования в этой области дизайна еще не до конца поняты. Проблема в том, что, с одной стороны, мы хотим как можно скорее отклонить недопустимые блоки, но, с другой стороны, мы не хотим застрять в разрыве цепочки или откладывать обработку того, что на самом деле является главной цепочкой. Системный способ решения этой проблемы остается открытой проблемой для будущей работы.

Хотя мы видели недавние примеры (например, CVE 2018–17144 в BTC), затрагивающие, по крайней мере, две кодовые базы, насколько нам известно, это первое скоординированное раскрытие уязвимости безопасности в таком большом количестве (более 20) независимых криптовалют. Учитывая количество форков и повторного использования кода в криптовалютах, мы ожидаем появления таких уязвимостей в будущем. Мы обнаружили, что между этими основами кода было мало единообразия в процессе обеспечения безопасности. Например, для большинства из них не было выделенного контакта по безопасности. Внедрение лучших практик для скоординированных раскрытий может принести пользу всей экосистеме.

[1] Идея этой уязвимости возникла летом 2018 года, когда Эндрю Миллер работал с разработчиками Unit-E. Мы благодарим Маттео Сумбераза и Джила Данцигера за полезные обсуждения и Фонд DTR ( https://dtr.org/ ) за исследовательский грант.

[2] Emercoin внедрил эвристику для обнаружения уязвимостей. https://github.com/emercoin/emercoin/commit/ec32762b99cc68fb9abb2909dda96bc7a13bd819

[3] Скользящие контрольные точки в Qtum https://github.com/qtumproject/qtum/commit/8d208d0bee8449c1e4a3904ff3fc97ed26156648

[4] Примеры специальных проверок для PoS можно найти здесь: https://github.com/peercoin/peercoin/blob/ebb4003ce8367501020181f7e734d52c4b1ab5ea/src/main.cpp#L2564

[5] Мы обратились к некоторым монетам по электронной почте, указав их веб-страницу или функцию «отправить заметку»

[6, *] Мы пытались связаться с PIVX несколько раз, начиная с ноября, через [ контактную форму на их веб-сайте ]. Только во время написания этого поста мы поняли, что [ PIVX также запустил проект по хакеронам ]. Мы отмечаем, что даже на сегодняшней странице [ страница с сообщениями об ошибках на самом сайте PIVX ] вообще не упоминается проект хакерона.

[**] StratisX перешел на реализацию C # со своей уязвимой базы кода C ++.

Эдвард Сноуден объясняет блокчейн и биткоин своему адвокату

В новой книге «Конец доверия», выпущенный Фондом Электронных Рубежей, известный информатор Эдвард Сноуден в разговоре со своим адвокатом Беном Вицнером обсуждает блокчейн и то, как он может изменить интернет и доверие в нём.

В течение последних пяти лет я с Эдвардом Сноуденом говорил почти каждый день; большинство разговоров так или иначе были связаны с юридическими вопросами. Иногда мы встречались в Москве за рюмкой водки (для меня) и молочным коктейлем (для него). Но по большей части наше общение велось на защищенных платформах по обмену сообщениями — канале, который был удобен и понятен для него, но немного непривычен для меня. Наши мнения во многом были схожи, но мировоззрения в целом — совершенно разные: иногда я упрекаю его в солюционизме; он меня — в инкрементализме. Continue reading

staking.live – простой POS пул. Отзывы.

staking.live

Новый staking.live – простой POS пул для монет поддерживающих эту технологию. Появился он недавно.  По видимому кое-какие детали там дорабатываются.  Регистрация на пуле здесь.

Монет пока немного, но стакинг лив пул работает. У меня лежит на нем для теста 10 0000 монет CDM. В день приходит на них до 50 монет.

staking.live

Таблица монет. Complet eco-system that allow you to track all your positions and get the most profit out of your pos coins with an powerfull intuitive platform. Our team at your service brings constant evolutions according to your choices.

Continue reading

mintnodes – пассивный заработок на криптовалюте. Отзывы.

Сегодня mintnodes это один из известных шареднод(POS пулов), с помощью которого можно организовать пассивный заработок на криптовалюте. Зарегистрироваться на mintnodes.  Существуют и подобные шареднод(POS пулы), например Stakecube

Таблица монет mintnodes

Кратко, суть таких (минтнод) сервисов: собираются монеты с вкладчиков в общую “кучу”, и соответственно на такую сумму начинает работать POS значительно результативней, чем на “копейки” отдельного вкладчика. Приходящие вознаграждения за POS затем распределяются сервисом, согласно процентному участию в “доле”. Таким же образом в сервисе работают мастерноды “вскладчину”. Например, для запуска мастерноды нужно 1000 монет.  Вкладчики собирают эту сумму сообща, после этого нода стартует и вознаграждения с ноды распределяются вкладчикам исходя из % участия. Идея гениально проста 🙂 Continue reading