<unnamed>

Public Key

npub186h7xm74e8dqvz64kzhx8aq3j47lwf3emlxl7w8j0d0thrth65vs9y2s83

Profile Code

nprofile1qqsratlrdl2unksxpd2mptnr7sge2l0hycualn0l8re8kh4m34ma2xgpzpmhxue69uhkummnw3ezuamfdejs696xgl

Publishing to

nostr.wine

Last Notes

2023-06-09 15:03:09 CEST

- reply

📅 Original date posted:2021-07-15
📝 Original message:
What would happen in 2) if the node has data but the peer returned an
incorrect state?
On Wed, Jul 14, 2021, 20:13 Christian Decker <decker.christian at gmail.com>
wrote:
> Not quite sure if this issue is unique to eltoo tbh. While in LN-penalty
> loss-of-state equates to loss-of-funds, in eltoo this is reduced to
> impact only funds that are in a PTLC at the time of the loss-of-state.
>
> We have a couple of options here, that don't touch the blockchain, and
> are therefore rather lightweight:
>
> 1) Do nothing and keep the incentive to keep up to date backups. It
> still is a reduction in risk w.r.t. LN-penalty, since this is just an
> append only log of secrets, and old secrets don't harm you like
> attempting to close with an old commitment would.
> 2) Use the peer-storage idea, where we deposit an encrypted bundle with
> our peers, and which we expect the peers to return. by hiding the fact
> that we forgot some state, until the data has been exchanged we can
> ensure that peers always return the latest snapshot of whatever we gave
> them.
>
> The latter is the encrypted-blob idea that Rusty has been proposing for
> a while now.
>
> Cheers,
> Christian
>
> Anthony Towns <aj at erisian.com.au> writes:
> > Hello world,
> >
> > Suppose you have some payments going from Alice to Bob to Carol with
> > eltoo channels. Bob's lightning node crashes, and he recovers from an
> > old backup, and Alice and Carol end up dropping newer channel states
> > onto the blockchain.
> >
> > Suppose the timeout for the payments is a few hours away, while the
> > channels have specified a week long CSV delay to rectify any problems
> > on-chain.
> >
> > Then I think that that means that:
> >
> > 1) Carol will reveal the point preimages on-chain via adaptor
> > signatures, but Bob won't be able to decode those adaptor signatures
> > because those signatures will need to change for each state
> >
> > 2) Even if Bob knows the point preimages, he won't be able to
> > claim the PTLC payments on-chain, for the same reason: he needs
> > newer adaptor signatures that he'll have lost with the state update
> >
> > 3) For any payments that timeout, Carol doesn't have any particular
> > incentive to make it easy for Bob to claim the refund, and Bob won't
> > have the adaptor signatures for the latest state to do so
> >
> > 4) But Alice will be able to claim refunds easily. This is working how
> > it's meant to, at least!
> >
> > I think you could fix (3) by giving Carol (who does have all the adaptor
> > signatures for the latest state) the ability to steal funds that are
> > meant to have been refunded, provided she gives Bob the option of
> claiming
> > them first.
> >
> > However fixing (1) and (2) aren't really going against Alice or Carol's
> > interests, so maybe you can just ask: Carol loses nothing by allowing
> > Bob to claim funds from Alice; and Alice has already indicated that
> > knowing P is worth more to her than the PTLC's funds -- otherwise she
> > wouldn't have forwarded the PTLC to Bob in the first place.
> >
> > Likewise, everyone's probably incentivised to negotiate cooperative
> > closes instead of going on-chain -- better privacy, less fees, and less
> > delay before the funds can be used elsewhere.
> >
> > FWIW, I think a similar flaw exists even in the original eltoo spec --
> > Alice could simply decline to publish the settlement transaction until
> > the timeout has been reached, preventing Bob from revealing the HTLC
> > preimage before Alice can claim the refund.
> >
> > So I think that adds up to:
> >
> > a) Nodes should share state on reconnection; if you find a node that
> > doesn't do this, close the channel and put the node on your enemies
> > list. If you disagree on what the current state is, share your most
> > recent state, and if the other guy's state is more recent, and all
> > the signatures verify, update your state to match theirs.
> >
> > b) Always negotiate a mutual/cooperative close if possible, to avoid
> > actually using the eltoo protocol on-chain.
> >
> > c) If you want to allow continuing the channel after restoring an old
> > state from backup, set the channel state index based on the real
> time,
> > eg (real_time-start_time)*(max_updates_per_second). That way your
> > first update after a restore from backup will ensure that any old
> > states that your channel partner may not have told you about are
> > invalidated.
> >
> > d) Accept that if you lose connectivity to a channel partner, you will
> > have to pay any PTLCs that were going to them, and won't be able
> > to claim the PTLCs that were funding them. Perhaps limit the total
> > value of inbound PTLCs for forwarding that you're willing to accept
> > at any one itme?
> >
> > Also, layered commitments seem like they make channel factories
> > complicated too. Nobody came up with a way to avoid layered commitments
> > while I wasn't watching did they?
> >
> > Cheers,
> > aj
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210715/54d800a3/attachment.html>

2023-06-07 17:29:47 CEST

- reply

📅 Original date posted:2015-02-05
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
I believe, we are still talking about transactions of physical people in physical world. So yes, it's proximity based - people tell the words by mouth. :)
In case of RedPhone, you read those words verbally over not-yet-verified channel relying on difficulty of spoofing your voice. Also the app remembers the public keys, so you don't need to verify second time.
I suggest you to try RedPhone (called Signal on iPhone) yourself. It's free/open source, Internet-based and end-to-end encrypted. You may find it useful some day. Also I'm willing to help you with trying it after I wake up. (~8 hours: Send me private e-mail if you want to.)
Dňa 6. februára 2015 1:22:23 CET používateľ Eric Voskuil <eric at voskuil.org> napísal:
>
>On 02/05/2015 04:04 PM, MⒶrtin HⒶboⓋštiak wrote:
>> That's exactly what I though when seeing the RedPhone code, but after
>> I studied the commit protocol I realized it's actually secure and
>> convenient way to do it. You should do that too. :)
>
>I was analyzing the model as you described it to me. A formal analysis
>of the security model of a particular implementation, based on
>inference
>from source code, is a bit beyond what I signed up for. But I'm
>perfectly willing to comment on your description of the model if you
>are
>willing to indulge me.
>
>> Shortly, how it works:
>> The initiator of the connection sends commit message containing the
>> hash of his temporary public ECDH part, second party sends back their
>> public ECDH part and then initiator sends his public ECDH part in
>> open. All three messages are hashed together and the first two bytes
>> are used to select two words from a shared dictionary which are
>> displayed on the screen of both the initiator and the second party.
>
>> The parties communicate those two words and verify they match.
>
>How do they compare words if they haven't yet established a secure
>channel?
>
>> If an attacker wants to do MITM, he has a chance of choosing right
>> public parts 1:65536. There is no way to brute-force it, since that
>> would be noticed immediately. If instead of two words based on the
>> first two bytes, four words from BIP39 wordlist were chosen, it would
>> provide entropy of 44 bits which I believe should be enough even for
>> paranoid people.
>>
>> How this would work in Bitcoin payment scenario: user's phone
>> broadcasts his name, merchant inputs amount and selects the name from
>> the list, commit message is sent (and then the remaining two
>> messages), merchant spells four words he sees on the screen and buyer
>> confirms transaction after verifying that words match.
>
>So the assumption is that there exists a secure (as in proximity-based)
>communication channel?
>
>e
>
>> 2015-02-06 0:46 GMT+01:00 Eric Voskuil <eric at voskuil.org>:
>>> On 02/05/2015 03:36 PM, MⒶrtin HⒶboⓋštiak wrote:
>>>>> A BIP-70 signed payment request in the initial broadcast can
>resolve the
>>>>> integrity issues, but because of the public nature of the
>broadcast
>>>>> coupled with strong public identity, the privacy compromise is
>much
>>>>> worse. Now transactions are cryptographically tainted.
>>>>>
>>>>> This is also the problem with BIP-70 over the web. TLS and other
>>>>> security precautions aside, an interloper on the communication,
>desktop,
>>>>> datacenter, etc., can capture payment requests and strongly
>correlate
>>>>> transactions to identities in an automated manner. The payment
>request
>>>>> must be kept private between the parties, and that's hard to do.
>>>>
>>>> What about using encryption with forward secrecy? Merchant would
>>>> generate signed request containing public ECDH part, buyer would
>send
>>>> back transaction encrypted with ECDH and his public ECDH part. If
>>>> receiving address/amount is meant to be private, use commit
>protocol
>>>> (see ZRTP/RedPhone) and short authentication phrase (which is hard
>to
>>>> spoof thanks to commit protocol - see RedPhone)?
>>>
>>> Hi Martin,
>>>
>>> The problem is that you need to verify the ownership of the public
>key.
>>> A MITM can substitute the key. If you don't have verifiable identity
>>> associated with the public key (PKI/WoT), you need a shared secret
>(such
>>> as a secret phrase). But the problem is then establishing that
>secret
>>> over a public channel.
>>>
>>> You can bootstrap a private session over the untrusted network using
>a
>>> trusted public key (PKI/WoT). But the presumption is that you are
>>> already doing this over the web (using TLS). That process is subject
>to
>>> attack at the CA. WoT is not subject to a CA attack, because it's
>>> decentralized. But it's also not sufficiently deployed for some
>scenarios.
>>>
>>> e
>>>
- --
Odoslané z môjho Android zariadenia pomocou K-9 Mail.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1
iI8EAREKADcFAlTUDKEwHE1hcnRpbiBIYWJvdmF0aWFrIDxtYXJ0aW4uaGFib3Zz
dGlha0BnbWFpbC5jb20+AAoJED6C3NvqapyUfUgA/2j6jQELBtSrNsle7ybGq1D8
uWgGwevguCnjPd0pEpWgAP42sS/ekCqs1v9wbART9fLprZTBk4YPllwXifss+9sa
zQ==
=J4w/
-----END PGP SIGNATURE-----