Jump to content
hash.bg - биткойн форум

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


Recommended Posts

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

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

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

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

Link to comment
Share on other sites

  • 2 weeks later...

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.

Link to comment
Share on other sites


[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
      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
Link to comment
Share on other sites

  • 2 weeks later...

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

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

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Create New...