Lightning Network - Какво е и кога ще се появи.

[ivan 1003]

 

[ivan 1003]

 

[ivan 1003]

 

[vamp111 3330]

999 пъти хакваха биткойна, сега почнват да хакват лайтнинга....

[ivan 1003]

Преди 1 час, vamp111 написа:

999 пъти хакваха биткойна, сега почнват да хакват лайтнинга....

По скоро описват възможността за DDOS атаките.

[ivan 1003]

 

[vamp111 3330]

Преди 1 час, ivan написа:

По скоро описват възможността за DDOS атаките.

ако използваш чужд компютър, т.е. клауд със сигурност може да те ddos-нат, това е проблема на къстодиал портфейлите

но в основата на биткойн и LN е да си подкараш собствен нод, сам да си валидираш транзакциите, сам да излъчваш LN такива, сам да си менажираш каналите сещаш се... 

[ivan 1003]

 

[ivan 1003]

 

[vamp111 3330]

https://decrypt.co/10655/lightning-rod-offline-payments-bitcoin-lightning-network

New Lightning Rod protocol enables Bitcoin payments to be sent between two Lightning Network nodes that are not online.

[ivan 1003]

Lightning Network Daemon - special WHATSAT edition

This repo is a fork of lnd that demonstrates how the Lightning Network can be used as an end-to-end encrypted, onion-routed, censorship-resistant, peer-to-peer chat messages protocol.

Recent changes to the protocol made it possible to attach arbitrary data to a payment. This demo leverages that by attaching a text message and a sender signature.

A Lightning payment delivers the message, but no actual money is paid. Because the sender uses a random payment hash, the receiver is not able to settle the payment. The failure message that is returned to the sender serves as a delivery confirmation.

This means that chatting is currently free. However, there is a future in which 'free failures' don't exist anymore. Nodes may start charging a prepaid relay fee and/or start rate limiting sources that produce too many failures. In that case, chatting over Lightning may switch to actually settling the messaging payments and dropping off a few millisats at every hop.

 

Дали тази идея ще се развие не знам. Като идея е супер, като техническа реализация не знам, може би ще натовари излишно ln мрежата или ще се окаже, че спокойно може да носи един световен чат.

Дали света има нужда от енд то енд криптира чат, който да не може да цензурира, защото е децентрализиран, няма значение, ще го има. Въпроса е да ли ще бъде изграден върху биткойн/ln.

[vamp111 3330]

 

[ivan 1003]

https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002288.html

[Lightning-dev] Potential Minor Sphinx Privacy Leak and Patch

Hi y'all,

A new paper analyzing the security of the Sphinx mix-net packet format [1]
(and also HORNET) has recently caught my attention. The paper is rather long
and very theory heavy, but the TL;DR is this:

    * The OG Sphinx paper proved various aspects of its security using a
      model for onion routing originally put forth by Camenisch and
      Lysyanskaya [2].
    * This new paper discovered that certain security notions put forth in
      [2] weren't actually practically achievable by real-world onion
routing
      implementations (in this case Onion-Correctnes), or weren't entirely
      correct or additive.  New stronger security notions are put forth in
      response, along with extensions to the original Sphinx mix-net packet
      format that achieve these notions.
    * A flaw they discovered in the original Sphinx paper [3], can allow an
      exit node to deduce a lower bound of the length of the path used to
      reach it. The issue is that the original paper constructs the
      _starting packet_ (what the exit hop will receive) by adding extra
      padding zeroes after the destination and identifier (we've more or
      less revamped this with our new onion format, but it still stands).
      An adversarial exit node can then locate the first set bit after the
      identifier (our payload in this case), then use that to compute the
      lower bound.
     * One of the (?) reference Sphinx implementations recognizes that this
       was/is an issue in the paper and implements the mitigation [4].
     * The fix on our end is easy: we need to replace those zero bytes with
       random bytes when constructing the starting packet.

I've created a PR to lnd's lightning-onion PR implementing this mitigation
[5].  As this changes the starting packet format, we also need to either
update the test vectors or we can keep them as is, and note that we use
zeroes so the test vectors are fully deterministic. My PR to the spec
patching the privacy leak leaves the test vectors untouched as is [6].

With all that said, IMO we have larger existing privacy leaks just due to
our unique application of the packet format. As an example, a receiver can
use the CLTV of the final HTLC to deduce bounds on the path length as we
have a restricted topology and CLTV values for public channels are all
known. Another leak is our usage of the variable length onion payloads which
a node can use to ascertain path length since they space they consume counts
towards the max hop count of 20-something.

In any case, we can patch this with just a few lines of code (fill out with
random bytes) at _senders_, and don't need any intermediate nodes to update.
The new and old packet construction algos are compatible as packet
_processing_ isn't changing, instead just the starting set of bytes are.

As always, please double-check by interpretation of the paper, as it's
possible I'm missing something. If my interpretation stands, then it's a
relatively minor privacy leak, and an easy low-hanging fruit that can be
patched without wide-spread network coordination.

-- Laolu

[ivan 1003]

 

[vamp111 3330]

https://kumo.chat/

goodbye mIRC via Lightning

[rippleche 44]

И за вс пари искат вече

[vamp111 3330]

е да ама ако например продаваш дрога или информации, няма ли да си платиш $1 за да се разберем безопасно в нета, вместо да ползваме mIRC примерно ?

[ivan 1003]

Интересни неща пише. LN има още доста да се развива, извървя не малко път, но taproot ще добави още доста възможности...за доразвитието му.

 

[vamp111 3330]

този подкаст още не е станал много известен, изслушай епизода, най-добрия до тук

 

[vamp111 3330]

доста интересен епизод, който съм пропуснал

 

[vamp111 3330]

 

[vamp111 3330]

Finex водят в класацията както винаги

 

[vamp111 3330]

ето и официалното обявление

https://www.bitfinex.com/posts/440

 

[vamp111 3330]

пропуснах това

това е част от стратегията на Финекс да си възвърнат Китайските клиенти, не се залъгвайте, чрез gift картите ежедневно се перат милиони долари, битрефил осигурява ликвидност, финекс субсидира, това е начин по който Китайците байпасват капитал контрол-а наложен в/у тях от правителството им, проблем който се разрешава и чрез iTunes акаунти ... 

[vamp111 3330]

два типа хора, едните по цял ден се взират в цената, другите строят и се подготвят за революцията