Topic: Lightning Network - page 29. (Read 776970 times)

Если очень хочется задрочить Чарли, находящуюся где-то на маршруте
между Алисой и Бобом - то можно сделать еще десяток Алис и десяток Бобов,
чтобы задрачивать Чарли параллельно с десяти узлов.

Я повторяю - не вижу профита в подобной дрочке. Наверное, это как-нибудь
решается причем на более низком сетевом уровне - отрубаются какие-то
IP-адреса, которые создают слишком большой трафик и нагрузку. Поставить
рабочий компьютер в сеть с открытыми портами - это вам не под виндой и за
натом сидеть на домашней машине.

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

Мне это понятно.
Мы начали (и давайте вернемся) с вопроса - задрочить сеть.
Есть Алиса со своими открытыми каналами. Есть Боб со своими каналами.
Боб - на самом деле не просто Боб, а бойфренд Алисы.
И в промежутке между кувырканием в кровати у них возникла мысль поразвлечься.
Боб выключает свою ноду.
А Алиса пытается отправить ему 0.0001 биткойна и смотрит, как сеть (не вся, но кто-то) старается
проложить маршрут, которого не существует, потому что нода Боба просто выключена
физически.

Может такое быть? В принципе, да. Может не так конкретно, но что-то в этом роде.

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

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

Если во время прохождения платежа, какой-то из платёжных каналов на маршруте оказывается недоступен, источник платежа (не дожидаясь разрушения платёжного канала по таймауту) отправляет отмену платежа по всей цепочке, строит новый маршрут и повторяет всё заново. У реальной молнии такие неудачные попытки можно сравнить с ветвлением лидера (светящиеся отростки).

После успешного достижения платежа до получателя, происходит снятие блокировки по всему платёжному каналу (с обратной стороны, от получателя). Это можно сравнить непосредственно с самой молнией.

Мы просто путаемся, потому что иногда под словом Алиса подразумеваем человека Алису,
а иногда её ноду с софтом, которая является вершиной в графе LN.

Тут есть вроде бы неплохое описание LN:
https://bitnovosti.com/2016/06/22/understanding-the-lightning-network/

Правда, рассматривается создание канала. Создание маршрута из нескольких каналов надо смотреть в другом месте.

Блеать. Каналы - это адреса с ненулевым балансом в обычной биткойн-сети.
Их устанавливает Алиса ручками заранее. Нода не открывает каналы в процессе работы.

Какие в пизду сидеры? Алиса знает публичный ключ Чарли - единственным с кем у нее
открыт канал, допустим. Задача - установить TCP/IP соединение с кем-то и проверить, что тот,
кто выдает себя за Чарли действительно им является. Эта задача решается без всяких "сидеров"

То есть алгоритм такой:
А: эй сидеры, у кого из вас открыт канал с Б
Ч: у меня открыт
А: установи ка Ч канал со мной
Ч: установил
А: вот биткоин, передай его Б
Ч: передал.

так что ли?

А если в окружении Алисы не найдется Чарли, то типа все?

Тут все просто.

Если Алиса открыла канал на Чарли, а Чарли упал в оффлайн,
то проводить лайтнинг-платежи Алиса не может, если, конечно у нее не открыты ещё
с кем-то каналы. Всё.

Канал на безвременно почившего Чарли Алиса может закрыть честно, получив через
какой-то промежуток времени свою долю из канала.

Не мешайте в кучу установку TCP/IP соединения и протокол лайтнинга.
Сперва мы устанавливаем соединение, потом по нему отправляем данные.
Если не можем установить соединение - считаем что комп контрагента выключен.

При установке соединения никакие промежуточные узлы не дрочатся.

Тогда все то же самое но не для А и Б, а для А и Ч.
Алиса не может подцепиться к Чарли напрямую в 99% случаев. Ей нужно окружение из сидеров с реальными внешними ип адресами. Сидеры работают как прокси. Дальше все то же самое: проксям надо проверять транзакции на валидность, а контрагентов на онлайность. Иначе сидеров заспамят - к гадалке не ходить.

Сперва Алиса строит маршрут до Боба
Допустим, Алиса имеет канал до Чарли, а Чарли до Боба.
Алиса обращается к Чарли: "эй, Бобу хочу отправить 1 биткойн"
Чарли смотрит - находится ли Боб в онлайне, есть ли открытый канал до Боба и хватает ли в нем средств.
Если все выполняется - Чарли с Бобом меняют состояние канала между ними - то есть Чарли пересылает Бобу биткойн.
После этого Чарли предъявляет Алисе: "зырь, я отправил Чарли биткойн, значит теперь и в нашем с тобой канале
один биткойн перетек на мою сторону"

Если Боб в оффлайне - то Чарли не может сам изменить состояние канала и просто
отвечает Алисе, что платеж провести нельзя. (По идее может, но это чревато)

Это моё вольное изложение процесса. Всё может быть совсем не так.

Смысл в том, что транзакция не просто гуляет по сети. У нее, как у TCP-пакета есть маршрут
от нода к ноде. И задрочить можно только ноды на этом маршруте.

Я не знаком с протоколом, поэтому не знаю структуру трафика.
Рассуждаю из общих знаний о п2п сетях. В частности о сети биткоина.
1. Алиса хочет послать Бобу 1 биткоин, но ни у Алисы ни у Боба нет внешнего ип адреса
2. Алиса формирует транзакцию и посылает ее своему окружению: тем у кого есть выделенный адрес
3. Транзакция проходит по п2п цепочке нод и доходит до Боба.

Теперь про лайтинг
1. В лайтинге обязательно должен быть описанный выше механизм помимо прямого соединения, потому что андроид это хорошо, а динамик днс умеют настраивать примерно 0.0% юзеров.
2. Алиса посылает Бобу 0.000001 биткоин, но Боб в оффлайне. Какие действия у проксирующих нод?
По логике они должны друг другу посылать эту транзакцию, пока не кончится какой-нибудь ттл (время жизни).
Вопрос1: удовлетворится ли Алиса тем, что ее транзакция исчезла в небытие или она попробует послать транзакцию еще 100500 раз через каждые полсекунды?
Вопрос2: что будут делать прокси-ноды с транзакциями Алисы? Они их будут забывать или где-то запоминать? Как ноды защищаются от ддоса?
Вопрос3: если Боба не существует в принципе, то прокси-ноды смогут об этом как-то узнать?

А они сегодня служат в качестве проксей? И действительно ли они не могут проверить
трафик в этом режиме? Я не знаю ответ на эти вопросы, да в целом и ддосить сеть -
занятие бессмысленное на мой взгляд.

Опять позвольте не согласиться. Соединение будет напрямую: ddns просто вернёт (или не вернёт) IP адрес, а дальше уже прямое соединение, "без посредников и прокладок". Однако, посредников на уровне tcp и без ddns хватает.

П.С. было время полчаса, погуглил. Сейчас настройки ноды не поддерживают доменные имена, только IP. Но заявка на GitHub на добавление такой возможности есть.
П.С.С я не понимаю о каком трафике вы говорите (платёжном или служебном(gossip messages)) когда хотите спамить, поэтому, к сожалению, не могу аргументированно поучаствовать в основном обсуждении.

Дак вот и я о том же.
Есть два варианта:
1. Прямое соединение
2. Соединение через прокладку.

Первый вариант возможен далеко не всегда. Но если прикрутить динамик днс, то создастся видимость прямого подключения. Хотя это тоже через прокладку будет, но это прокладка на уровне tcp.
Второй вариант самый простой и надежный кода прокладкой является пиринговая сеть. Но чтобы пиринговая сеть работала как прокси, в ее протокол должны быть встроены команды прокси. Это уровень выше чем tcp. Это более высокий уровень протокола пиринговой сети.

Так вот, в биткоине каждая нода может работать как прокси - это заложено в протоколе. Но биткоин не заспамить потому что если посылать нодам всякую инвалидную чушь, то тебя быстро забанят ибо ноды проверяют все что пересылают другим.

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

Я спорю (смотри выше).
Dynamic DNS уже давно встраивается в роутеры. Текущая реализация лайтнинг не поддерживает решение напрямую, но при небольшой доработке (настройке сетевого оборудования на обоих сторонах канала), вполне может заработать при отсутствии у нод постоянных IP адресов.

Здесь товарищ описывает настройку ноды без внешнего IP (https://tgraph.io/Gajd-po-zapusku-i-monetizacii-nody-Bitcoin-Lightning-10-02?tg_rhash=6f689bcee5d75f):

Ясен пень! Кто ж с этим спорит? Поэтому я выше и написал, что андроид-кошелёк создаёт односторонний канал с полноценной LN-нодой. Под полноценной нодой, я имею в виду ноду, имеющую белый IP и способную принимать входящие TCP-соединения на какой-то там порт.

Ну хватит вам упорствовать не по делу, а?
Как клиенты на телефонах (да и из дома мы все сидим за NAT) взаимодействуют
с биткойн-сетью? Вот так же можно и с лайтнинг-сетью взаимодействовать, если
есть возможность хоть с кем-то соединиться - дальше уже пиринговая сеть передаст
запрос.

Но!

Если у вас лично нет открытого канала - то вы не можете просто так скачать
клиента из гугль-плея и сразу отправить платеж в магазин за стикер. Вы сперва
создаете канал (по сути дела вносите авансовый платеж), а потом этот аванс
выюзываете постепенно.

Теперь едем дальше. Может нодой лайтнинг-сети выступать устройство, которое
заходит в интернет время от времени? Теоретически, да. Только при этом возникают
проблемы:

- мы не контролируем то, что другая сторона канала не закрыла канал читерским образом пока мы были в офлайне
- никто не может создать канал с нами пока мы в оффлайне, да и в онлайне не достучатся
- через ноду не проходит трафик, многие заводят ноды в расчете на копеечную прибыль от маршрутизации
- большой объем информации для синхронизации данных и задержки с этим связанные

Мой ответ не относится напрямую к лайтнинг нетворк и касается утверждения про невозможность установки TCP соединений. Технически это возможно с помощью сервиса DynDNS.
П.С. Это не работает для абонентов 4G мобильных сетей.

Еще раз: если ни у одной стороны обмена нет выделенного ип адреса, то они не смогут установить друг с другом TCP соединение. Никак. Потому что вот тут: https://pubs.opengroup.org/onlinepubs/7908799/xns/connect.html
второй аргумент это тот самый ип адрес.