Re: [Lightning-dev] Interesting thing about Offered HTLCs

2022-03-16 Thread darosior via Lightning-dev
Miniscripts with duplicate keys are considered insane as it makes it too hard to reason about malleability (there is no CODESEPARATOR in Miniscript). A policy compiler would never produce such a Miniscript. Original Message On Mar 15, 2022, 4:26 PM, Eugene Siegel < elzei...@gma

Re: [Lightning-dev] Interesting thing about Offered HTLCs

2022-03-11 Thread darosior via Lightning-dev
Also, using Miniscript (whether in Segwit v0 or v1) would prevent this kind of surprises. And many potential others. :-) I'll post something soon about how we could integrate Miniscript in Lightning. Original Message On Mar 10, 2022, 2:55 PM, Eugene Siegel wrote: > Yes I think

Re: [Lightning-dev] [bitcoin-dev] [Pre-BIP] Fee Accounts

2022-02-19 Thread darosior via Lightning-dev
> Necromancing might be a reasonable name for attacks that work by getting an > out-of-date version of a tx mined. It's not an "attack"? There is no such thing as an out-of-date transaction, if you signed and broadcasted it in the first place. You can't rely on the fact that a replacement transac

[Lightning-dev] Dropping Tor v2 onion services from node_announcement

2021-06-01 Thread darosior via Lightning-dev
Hi all, It's been almost 9 months since Tor v2 hidden services have been deprecated. The Tor project will drop v2 support in about a month in the latest release. It will then be entirely be dropped from all supported releases by October. More at https://blog.torproject.org/v2-deprecation-timeline

Re: [Lightning-dev] Why should funders always pay on-chain fees?

2020-10-05 Thread darosior via Lightning-dev
Hi Bastien, > I think that *in some cases*, fundees should be paying a portion of the > commit-tx on-chain fees, > otherwise we may end up with a web-of-trust network where channels would only > exist between peers > that trust each other, which is quite limiting (I'm hoping we can do better).

Re: [Lightning-dev] DRAFT: interactive tx construction protocol

2020-02-11 Thread darosior via Lightning-dev
Hi niftynei and list, ‐‐‐ Original Message ‐‐‐ Le mardi, février 11, 2020 12:11 AM, lisa neigut a écrit : > Here's some thoughts I had on PoDLE's and lightning. An enormous > tip-of-the-hat is due to ZmnSCPxj for surfacing the work that JoinMarket has > done here already. > > - The i

Re: [Lightning-dev] DRAFT: interactive tx construction protocol

2020-02-02 Thread darosior via Lightning-dev
> Yes that's the reason I wrote the initiator can just announce its own and > receiver use it to sign the funding tx, even if receiver tip is backward. > Funding tx won't propagate from receiver mempool but that's fine if it does > from the initiator one. Ah, then we are back to my first

Re: [Lightning-dev] DRAFT: interactive tx construction protocol

2020-02-02 Thread darosior via Lightning-dev
Hi Antoine and all, About nLockTime fun thing is Lisa, Cdecker and I had this conversation to integrate it to C-lightning just yesterday. Unfortunately you need to add a "My tip is " to the openchannel msg, otherwise if you set nLockTime to tip. (cdecker) Moreover in case

Re: [Lightning-dev] DRAFT: interactive tx construction protocol

2020-02-02 Thread darosior via Lightning-dev
Sorry I wasn't clear enough in the \`(cdecker)\` paragraph. The funding transaction sig would actually fail verification if tip differs between funder and fundee. Darosior ( i'll stick with my pseudo, first names definitely don't have enough entropy :-) ) \ Original Message

Re: [Lightning-dev] Sphinx and Push Notifications

2020-02-02 Thread darosior via Lightning-dev
Hi Pavol, > 1) Is c-lightning going to support Sphinx or other form of spontaneous > payments? I think cdecker is working on integrating keysend to his noise plugin (https://github.com/lightningd/plugins/pull/68). > 2) Can a lightning node (such as lnd or c-lightning) send a push notification

Re: [Lightning-dev] DRAFT: interactive tx construction protocol

2020-01-31 Thread darosior via Lightning-dev
Hi ZmnSCPxj, Using joinmarket's PoDLEs is a great idea, and it seems preferable to using a transaction chain with a distinguishable SIGHASH. Just a naive question, what is described in https://gist.github.com/AdamISZ/9cbba5e9408d23813ca8#defence-2-committing-to-a-utxo-in-publicplaintext-at-the-

Re: [Lightning-dev] DRAFT: interactive tx construction protocol

2020-01-30 Thread darosior via Lightning-dev
Hi Lisa and all, Given the discussion about utxos snooping, I wondered if there was any obvious drawbacks of using a transaction chain construction ? Since the obvious target of the probing is the accepter, it seems that the opener needs to at least have something at stake in order to be reveal

Re: [Lightning-dev] On Path Privacy

2020-01-02 Thread darosior via Lightning-dev
Hi ZmnSCPxj, Just a nit to add for reference to this great writeup. > - Add random tweaks to your channel traversal costs. > - This is done currently by the C-Lightning route randomization > feature, but note that it is currently set to up to a +/-5% tweak. > - [This paper](ht