эта история относительно легко отслеживалась тоже из-за особенностей реализации конкретного кошелька, а не особенностей самого протокола
??
История хранится в самом блокчейне, если пользоваться легким клиентом — блокчейн свое существование не прекратит и история из него никуда не исчезнет. Его можно будет скачать и проанализировать все истории платежей…
Диаметры трубки на высоту подъема жидкости влияния не оказывают, все в физике капилляров по которым сконденсированная жидкость должна возвращаться в нагревающую область. Высота поднятия жидкости в капиллярах
В теории с помощью тепловых трубок можно на неограниченную высоту опускать тепло, если собирать тепловод из множества трубок. Но мне подобное применении в технике не встречалось.
Есть какое то другое название… вспомнить не могу
Разница в том что в «теплосваях» жидкость под действием гравитации опускается, и теплая часть строго внизу. А в теплотрубке горячая часть все равно где находится — жидкость перемещается в нее по капиллярам, в том числе и в более высокий участок.
А капилляры имеют ограничения по смачиваемости.
Судя по описанию используется только троица — приватный ключ, публичный ключ и адрес который свертка публичного.
Как используется блокчейн из статьи неясно, может в видео что то еще есть
Вообще есть способ отправить две транзакции ссылающиеся на один выход. Когда то пришлось такое делать как раз из за маленькой комиссии. Пришлось сделать новый кошелек, импортировать туда приватный ключ и сформировать транзакцию в оффлайне, пока пул транзакций моей ноды не получил застрявшую. Со старым кошельком такое было сделать невозможно — он как раз хранил информацию о застрявшей и сразу ее в сеть отправлял.
В блокчейн попала транзакция с большей комиссией.
Похоже что описание в статье упрощенное.
Вот тут в примере алгоритма видно что помимо секрета(который в вашей статье ключ хэширования) используются ECDA подписи и транзакцию Алисы нельзя изменить используя только секрет. A creates TX1: "Pay w BTC to <B's public key> if (x for H(x) known and signed by B) or (signed by A & B)"
B creates TX3: "Pay v alt-coins to <A-public-key> if (x for H(x) known and signed by A) or (signed by A & B)"
А если Боб перехватив транзакцию Алисы в пуле транзакций пока она еще не попала в блокчейн создаст конкурирующую транзакцию? Тогда по идее в эфириуме в пуле транзакций будут две конкурирующие транзакции, а которая из них попадет в блокчейн выбирать уже майнеру?
Или от такого сценария тоже защита предусмотрена?
Ну это не с ума вовсе… Вряд ли Саша когда то с ума сойдет — он весьма целеустремленно и методично сражается со скукой, с ума сходят когда непонятно с чем сражаться.
Под фейковыми опровержениями не с ложным пруфом, а верным. Скорее правильно назвать их скам опровержениями. Основной блокчейн же понятия не имеет на какой стадии рутчейн и где там конец цепи.
какая-то сумма должна вычитаться с fee и идти на поощрение валидаторов.
посылается вывод не с конца рутчейна, потом опровергается — валидатор получает профит
Proof-of-Stake в основном возник для защиты новых альткоинов от атак 51 перед майнерами криптовалют постарше, в виде гибридных криптовалют. А экономия электричества это уже побочное явление.
История хранится в самом блокчейне, если пользоваться легким клиентом — блокчейн свое существование не прекратит и история из него никуда не исчезнет. Его можно будет скачать и проанализировать все истории платежей…
Высота поднятия жидкости в капиллярах
В теории с помощью тепловых трубок можно на неограниченную высоту опускать тепло, если собирать тепловод из множества трубок. Но мне подобное применении в технике не встречалось.
Разница в том что в «теплосваях» жидкость под действием гравитации опускается, и теплая часть строго внизу. А в теплотрубке горячая часть все равно где находится — жидкость перемещается в нее по капиллярам, в том числе и в более высокий участок.
А капилляры имеют ограничения по смачиваемости.
Как используется блокчейн из статьи неясно, может в видео что то еще есть
Теперь вот после вашего поста все стало на свои места.
В блокчейн попала транзакция с большей комиссией.
Вот тут в примере алгоритма видно что помимо секрета(который в вашей статье ключ хэширования) используются ECDA подписи и транзакцию Алисы нельзя изменить используя только секрет.
A creates TX1: "Pay w BTC to <B's public key> if (x for H(x) known and signed by B) or (signed by A & B)"B creates TX3: "Pay v alt-coins to <A-public-key> if (x for H(x) known and signed by A) or (signed by A & B)"
Или от такого сценария тоже защита предусмотрена?
посылается вывод не с конца рутчейна, потом опровергается — валидатор получает профит