drileb

И по какому принципу они вообще генерируются(v3)?

Генерируется ключевая пара размером 256 бит по алгоритму ed25519. Публичный ключ затем кодируется в base32 вместе с некоторыми служебными данными - номером версии (3) и контрольной суммой. Получившаяся строка и является доменом в зоне onion.

Если делать полный перебор (а других вариантов я не вижу), то нужно сгенерировать до 2²⁵⁶ ключевых пар. Если взять миллиард компьютеров, которые будут одновременно и без пересечений друг с другом генерировать ключевую пару каждую наносекунду, то все пары можно перебрать примерно за 36*10⁴¹ млрд лет, что кажется мне достаточно малым шансом, учитывая, что возраст вселенной всего чуть менее 14 млрд лет.

Надо отметить, что не все варианты из 256-битового пространства удовлетворяют ed25519. Но даже если отбросить 99% вариантов как невалидные и не тратить время на их генерацию, то перебор оставшихся 1% все равно будет невообразимо дольше возраста вселенной.

apt-get update
apt-get upgrade

Обновит всё.

Я бы сделал 2 таблицы:
1. Транзакции со счетом (его изменения + причины этого изменения). Только добавление.
2. Состояние счета на дату\время (дата\время, счет, id_юзера). В это таблицу мы только пишем, и ничего не меняем и не удаляем.

Такая структура позволит получить состояние счета за любой промежуток времени.

csrf токет по идее должен быть всегда уникальный (по крайней мере в рамках одной сессии) , судя по тому что у формы на onsubmit стоит "return false;", то могу предположить что форма отправляется через ajax, проверьте отправляется ли csrf-токен.
Форма отправляется на тот же сайт?
Или вы пытаетесь отправлять с локалки на хостинг форму? если так, то конечно будет 419, для этого и придуман csrf.

воспользуйтесь функцией array_column

$arr_new = array_column($arr, NULL, 'id');
print_r($arr_new);

SELECT * FROM `dle_post` WHERE CONCAT('|', `xfields`, '|') LIKE '%|key|123|%'

https://sqlize.online/sql/mysql80/8675613d79d56f40...