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

lisa neigut writes: >> With PoDLE this would not be possible I think, as you would not be able > to open the PoDLE commitment with the other node as the target (if we go > with the modified PoDLE which also commits to which node an opening is for, > to prevent the pouncing venus flytrap attack).

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

> With PoDLE this would not be possible I think, as you would not be able to open the PoDLE commitment with the other node as the target (if we go with the modified PoDLE which also commits to which node an opening is for, to prevent the pouncing venus flytrap attack). Good question. It should be

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

Good morning Rusty, niftynei, and list, > > > - Serial ids should be chosen at random > > > > > > - For multiparty constructions, the initiator MUST flip the bottom bit > > > of any received inputs before relaying them to a peer. > > > > > > - Collisions of serial ids between peers is a

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

ZmnSCPxj via Lightning-dev writes: > Good morning niftynei, > > >> Rusty had some suggestions about how to improve the protocol messages for >> this, namely adding a serial_id to the inputs and outputs, which can then be >> reused for deletions.  >> >> The serial id can then also be used as the

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

Good morning niftynei, waxwing, and list, > > Probably so that address reuse is not dinged, i.e. I have two UTXOs with > > the same address and want to make two different channels with different > > peers. > > Having 2 utxos locked to the same pubkey will map to a single H2 value > though,

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

Good morning waxwing, > > https://github.com/privacypass/challenge-bypass-extension/blob/master/docs/PROTOCOL.md > > While it's very different from our use-case (harder because not > client-server), Am still going through the document, but wanted to react to "not client-server" thing.

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

> Probably so that address reuse is not dinged, i.e. I have two UTXOs with the same address and want to make two different channels with different peers. Having 2 utxos locked to the same pubkey will map to a single H2 value though, which is what is used to flag utxo reuse. With a PoDLE you're

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

> One of the stated goals of implementing PoDLEs was to be "compatible with > JoinMarket", but I believe this compatibility goal only extends as far as the > H2 construction (and not the proof), so we're ok there with this tweak. Good point about H2 being cross-compatible, but I would not tie

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

Good morning niftynei, and waxwing, and list, > > s = k + H(kG || kJ || P || P2 || utxo || receiving-node) x > > > and as before transfer opening: (P, P2, u, s, e) with receiving-node > > implicitly reconstructed to do the verification of the Schnorr sig. It's > > basically a message in a

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

niftynei, ZmnSCPxj and list: Zmn** pinged me about this discussion and I thought I could add something directly: First, re: > I'd like to propose that we add a second commitment requirement to the PoDLE > that JoinMarket uses, to limit the use of a commitment's validity to be only > between

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

Hi darosior, niftynei, and list, waxwing replied the below text, and asked to propagate as well to lightning-dev. He has just recently re-subscribed to lightning-dev, but may be waiting for the necessary subscription notices or whatnot. Regards, ZmnSCPxj --- Re: Venus Flytrap attack

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

Good morning darosior, niftynei, and list, > > We could agree on an acceptable number of reuse in case on a non-malicious > failure from the initiator after a valid PoDLE exchange ? (credits ZmnSCPxj) The default of 3 for JoinMarket seems reasonable. > > Ok, so knowing where PoDLE originate

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

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

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

I'd like to propose that we add a second commitment requirement to the PoDLE that JoinMarket uses, to limit the use of a commitment's validity to be only between an initiator and a single peer. Otherwise you can enable something I'll call the "pouncing venus-flytrap attack"[1]. Venus-flytrap

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

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 initiating message (in the case of open channel, this would be `open_channel2`) is extended to include an 'H2' field in its TLV, a

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

> But if you impose the blockheight - 6 in the Lightning protocol level, and Lightning succeeds (meaning a substantial fraction of blockchain transactions are Lightning opens)... > --- then transactions with `nLockTime` equal to the block they are included in minus 5 will be more common than

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

Good morning lisa, > > I am unsure what is the purpose of this minus 6. > > The original motivation was to keep the funding transaction from being > rejected from the mempool in the case of a re-org, but as you pointed out, > the 'next block' is always at -par or ahead of the current chain tip,

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

> I am unsure what is the purpose of this minus 6. The original motivation was to keep the funding transaction from being rejected from the mempool in the case of a re-org, but as you pointed out, the 'next block' is always at -par or ahead of the current chain tip, so I'm not sure this

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

Good morning niftynei, > Rusty had some suggestions about how to improve the protocol messages for > this, namely adding a serial_id to the inputs and outputs, which can then be > reused for deletions.  > > The serial id can then also be used as the ordering heuristic for transaction > inputs

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

Rusty had some suggestions about how to improve the protocol messages for this, namely adding a serial_id to the inputs and outputs, which can then be reused for deletions. The serial id can then also be used as the ordering heuristic for transaction inputs during construction (replacing current

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

> 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

Good morning darosior, > 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 >

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

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

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

> The funding transaction sig would actually fail verification if tip differs between funder and fundee 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

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

Hey Darosior, You don't need a strict synchronization between both peers, just let nLocktime picked up by initiator and announce it at same time than feerate or at `tx_complete`. Worst-case, a slow-block-processing receiver may not be able to get the transaction accepted by its local mempool, but

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

Good morning darosior, > 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

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

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

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

Hey, Ok gotcha now. Re-read your prior post. Thanks for the feedback both of you! Thanks, Max > On Jan 29, 2020, at 9:00 PM, lisa neigut wrote: > >  > hi max — great question. PSBT is a great protocol for wallet interop but a > bit overweight for tx collaboration between two peers > >> On

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

Hi Max, Sorry by transaction format I didn't mean a binary transaction format, but format like we use in BOLT3 : https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md My concern is, e.g LN implementations setting nLocktime to 0x, Coinjoin wallets always

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

hi max — great question. PSBT is a great protocol for wallet interop but a bit overweight for tx collaboration between two peers On Wed, Jan 29, 2020 at 17:29 Max Dignan wrote: > Hey Antoine, > > Would PSBT (BIP 174 - > https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki) be a good >

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

Hey Antoine, Would PSBT (BIP 174 - https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki ) be a good solution to this? -Max___ Lightning-dev mailing list

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

Hey thanks for this proposal! 2 high-level questions: What about multi-party tx construction ? By multi-party, let's define Alice initiate a tx construction to Bob and then Bob announce a construction to Caroll and "bridge" all inputs/outputs additions/substractions in both directions. I think

[Lightning-dev] DRAFT: interactive tx construction protocol

Some of the feedback I received from the check-in for the dual-funding proposal this past Monday was along the lines that we look at simplifying for breaking it into smaller, more manageable chunks. The biggest piece of the dual-funding protocol update is definitely the move from a single peer