<unnamed>

Public Key

npub186h7xm74e8dqvz64kzhx8aq3j47lwf3emlxl7w8j0d0thrth65vs9y2s83

Profile Code

nprofile1qqsratlrdl2unksxpd2mptnr7sge2l0hycualn0l8re8kh4m34ma2xgpz4mhxue69uhhyetvv9ujumn0wd68ytnwv46qz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpp4mhxue69uhkummn9ekx7mqjertr6

Publishing to

relay.nostr.net

relay.damus.io

nos.lol

Last Notes

2023-06-09 13:06:43 UTC

- reply

📅 Original date posted:2022-08-31
📝 Original message:
Hi folks,
I think I've seen wallets supporting "send max" when a zero-amount invoice
was used. So isn't it a problem with the custodial service not supporting
it?
Whatever idea we figure out they can just refuse to implement it so we
can't force them into improving and being custodial they could steal
already, so that shouldn't be an issue.
Have a nice day!
Martin
On Sat, 27 Aug 2022 at 04:06, ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Good morning Rene,
>
> > Dear fellow Lightning Developers,
> >
> > I was recently on an event where the visitors have been gifted 10k sats
> on a custodial wallet. They could spend those sats via some web interface
> and an NFC card. During the event I was contacted by several plebs who were
> confused about one particular thing:
> > It was impossible for them to withdraw the full amount from the service.
> >
> > Pasting an invoice for 10k sats would not work as the custodial service
> required a fee budget of 1%. However if people submitted an invoice for
> 9900 sats the remaining 100 sats were usually not fully required for the
> fees. Thus the users may have had a leftover of for example 67 sats. Now
> the problem repeated on the residual amount. While some services seem to
> have a drain feature for such a situation I find this frustrating and was
> wondering if we could help directly on a protocol level.
> >
> > Here is my proposal for a simple solution to this specific problem:
> `option_recipient_pays_routing_fees`
> >
> > This would be a new flag in invoices signaling that the recipient is
> willing to pay for the routing fees by releasing the preimage even if the
> full amount has not been arrived in htlcs at the recipient.
> >
> > So the workflow would be the following:
> >
> > 1. Alice creates an invoice for 10k sats setting the
> `option_recipient_pays_routing_fees` flag in the invoice and passes it
> either to custodial user Bob or to her own custodial account.
> > 2. The payer parses the invoice and searches for a payment path or
> payment flow to Alice.
> > 3. Because `option_recipient_pays_routing_fee` is set, the onion is not
> constructed in a way that the final HTLC will be for the amount of 10k sats
> but rather in a way that the first htlc will be for 10k sats and the
> following HTLCs will be of decreasing value so that routing nodes are
> compensated properly.
> > 4. When the HTLC(s) arrive at Alice she will release the preimage if and
> only if not too many sats (e.g. 1% of the amount) are missing. Of course it
> would be good if the 1% was not hard coded in the protocol / software but
> configurable by Alice at the time of invoice creation.
> >
> > I think the main issue with this proposal is that instead of confusing
> users who wish to drain an account we may now have to educate users about
> two different invoice types. On the other hand I think this can probably
> easily be achieved via the current wide spread user interfaces. Of course
> it may be nice to have folks from the Bitcoin Design community to join this
> specific part of the discussion.
>
> In theory, trampoline routes / whatever-the-cool-name-is-now should fix
> this problem as well.
> I am referring to that scheme where the invoice contains an onion and a
> "trampoline" node that is the only node that can decrypt the first layer of
> the onion.
> The sender then has to route to the trampoline node, and the trampoline
> node then receives the rest of the onion.
>
> In this scheme, the receiver provides an encrypted route from some node to
> itself.
> As the receiver provides the route in order to gain privacy from the
> sender, the onus is on the receiver to deduct the fees from its received
> funds.
> i.e. the sender is only responsible for paying for fees up to the entry
> point of the trampoline.
>
> Thus, such a drain requirement simply means that the custodial service has
> to give its node ID.
> Then the receiver finds a route from the custodial service to itself, and
> encodes that in the trampoline onion, with a direct neighbor of the
> custodial service node as the trampoline.
> The custodial service then does not care about any fees as the receiver
> decided the route; the receiver knows exactly how much to expect (since it
> calculated the route).
>
>
> Of course, it is also possible as you propose, but any level-1-selfish
> custodial service will then always keep the remaining fee budget and always
> ensure that the receiver gets 99% of the value (or 100% -
> whatever_setting_they_chose), paying fees, and keeping the remaining 1% for
> itself.
> The receiver in this case cannot audit the route anyway, and thus cannot
> determine how much the true fees are; whereas in the trampoline case the
> route is specifically selected by the receiver.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> 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/20220831/26c6eb67/attachment.html>

2023-06-09 13:03:09 UTC

- 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 23:00:51 UTC

- reply

📅 Original date posted:2021-12-06
📝 Original message:I recommend you researching RGB: https://rgb-org.github.io/
On Mon, Dec 6, 2021, 11:21 Karl <gmkarl at gmail.com> wrote:
> Hi,
>
> I'm not a bitcoin developer.
>
> On Mon, Dec 6, 2021, 5:05 AM Héctor José Cárdenas Pacheco via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hello all,
>>
>> I’ve been thinking about how OP_RETURN is being used to create and trade
>> NFTs on Bitcoin (think RarePepes, SoG and other new ones) and was wondering
>> if it’s possible to
>>
>
> Do you have a link to any of these protocols?
>
> make transactions with this opcode via Lightning.
>>
>> More specific questions could be:
>>
>> 1. Can opcodes like OP_RETURN be inside a channel’s opening or
>> closing transaction?
>> 2. If so, could that OP_RETURN change hands within that channel or
>> network of channels?
>>
>> OP_RETURNs do not have ownership according to the bitcoin network. It is
> not hard to define a protocol that associates an OP_RETURN with ownership,
> and ownership could then be transferred via lightning by sending associated
> currency via lightning. Robustness improvements seem possible.
>
>
>> 1. If possible, could the OP_RETURN be divisible? Could one person
>> send a piece of a OP_RETURN just like one can do right now on the primary
>> ledger or would it need to maintain the OP_RETURN code intact?
>>
>> OP_RETURNs themselves do not have ownership, but you can define a
> protocol that gives them divisible ownership, including via lightning.
>
> I’m assuming that, if possible, this would need a protocol layer parallel
>> to Bitcoin/Lightning that stores and reads all Bitcoin transactions and the
>> ones which involve the node's channels as well as the ones with the
>> OP_RETURN, just like CounterParty does right now with the primary ledger.
>>
>> Thank in advance.
>> ——
>>
>> *Héctor Cárdenas*@hcarpach
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-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/bitcoin-dev/attachments/20211206/d86e56cb/attachment.html>

2023-06-07 15:29:47 UTC

- 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-----