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

[Rusty Russell]

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).
>
> Good question. It should be possible to do multi-channel open even with the
> PoDLE signature committing to a node_id.
>
> - An initiator can use the same utxo (h2) as their proof for multiple
> peers; the signatures passed to each peer will have to commit to that
> specific peer's node_id, however.
> - The revised PoDLE signature commitment requires every initiator to
> include at least one of their own inputs in the tx. Attempting to initiate
> an additional open etc using someone else's utxo's won't work (this is the
> pouncing venus flytrap attack which we're preventing). The initiator
> including at least one input is expected behavior, at least in the open
> case, since the opener has to cover the fees for the funding output.
> - Ideally, a node would remove the PoDLE TLV data from any 'forwarded'
> `tx_add_inputs` that isn't the input they're proving for, to prevent
> leaking information about which inputs belong to other parties. I say
> ideally here because even if you fail to do this, the peer can iterate
> through all the provided commitment proofs until one of them
> matches/verifies with the upfront provided PoDLE.

Yes, you need to PoDLE your own contribution I think, which means you
need one UTXO per contributor in the N-way-open who you want to
contribute a UTXO.

Consider Alice trying to create a single-tx to open a channel with both
Bob and Carol, and wants *both* of them to also contribute.

Alice sends her own UTXO1 with proof to Bob, he shares his UTXO back.
Alice sends her own UTXO2 with proof to Carol, she shares a UTXO back.
Alice sets the lower bit on the serial_id from Bob and sends to Carol,
and sets the lower on the serial_id from Carol and sends to Bob.  She
similarly reflects everything from Carol to Bob and vice-versa, and
sends both of them the two "channel opening" outputs.

Now all parties have the same tx; unless Bob and Carol chose the same
serial_ids (spec says random, but Bob and Carol don't get along).  But
this is trivially identifiable, and you give up on mutual opening.

Cheers,
Rusty.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[lisa neigut]

> 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 possible to do multi-channel open even with the
PoDLE signature committing to a node_id.

- An initiator can use the same utxo (h2) as their proof for multiple
peers; the signatures passed to each peer will have to commit to that
specific peer's node_id, however.
- The revised PoDLE signature commitment requires every initiator to
include at least one of their own inputs in the tx. Attempting to initiate
an additional open etc using someone else's utxo's won't work (this is the
pouncing venus flytrap attack which we're preventing). The initiator
including at least one input is expected behavior, at least in the open
case, since the opener has to cover the fees for the funding output.
- Ideally, a node would remove the PoDLE TLV data from any 'forwarded'
`tx_add_inputs` that isn't the input they're proving for, to prevent
leaking information about which inputs belong to other parties. I say
ideally here because even if you fail to do this, the peer can iterate
through all the provided commitment proofs until one of them
matches/verifies with the upfront provided PoDLE.



On Thu, Feb 13, 2020 at 12:18 AM ZmnSCPxj  wrote:

> 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 protocol error
> > > >
> > >
> > > I suppose we should define collision to mean "equal in all bits except
> the lowest bit".
> >
> > No, literally equal. i.e. you can only make this error by clashing with
> > yourself.
>
> hmm, I thought the entire point of having the low bit was that you could
> multifund in such a way that the initiator creates multiple channels
> simultaneously with multiple nodes?
> So you would have to take the UTXOs of one peer and give it to the other
> peer claiming it as your own.
> Or something.
>
> 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).
>
> Regards,
> ZmnSCPxj
>
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[ZmnSCPxj via Lightning-dev]

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 protocol error
> > >
> >
> > I suppose we should define collision to mean "equal in all bits except the 
> > lowest bit".
>
> No, literally equal. i.e. you can only make this error by clashing with
> yourself.

hmm, I thought the entire point of having the low bit was that you could 
multifund in such a way that the initiator creates multiple channels 
simultaneously with multiple nodes?
So you would have to take the UTXOs of one peer and give it to the other peer 
claiming it as your own.
Or something.

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

Regards,
ZmnSCPxj

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[Rusty Russell]

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 ordering heuristic for 
>> transaction inputs during construction (replacing current usage of BIP69). 
>> Inputs can be shared amongst peers by flipping the bottom bit of the 
>> serial_id before relaying them to another peer (as your own).
>
> What happens if the initiator deliberately provides serial IDs 0x1, 0x3,  
> while the acceptor naively provides serial IDs from `/dev/urandom`?

This is a feature, and one you might need to use if you have some
SIGHASH_SINGLE or other weirdness for one input.

> Then the balance of probability is that the initiator inputs and outputs are 
> sorted before the acceptor.
> Now, this is probably not an issue, since the initiator and acceptor both 
> know which inputs and outputs are theirs and not theirs, so they could just 
> reveal this information to anyone, so an actor providing such lousy serial 
> IDs is just hurting its own privacy relative to blockchain analysts, so 
> probably will not happen in practice.
>
> My initial reaction was to propose adding a secret-sharing round where the 
> resulting key is XORed to each serial ID before sorting by the XORed serial 
> ID, but this might be too overweight, and again the initiator is only hurting 
> its own privacy, and the two participants already know whose money is whose 
> anyway

>> > - nLocktime is always set to 0x
>>
>> - If a blockheight to be used as nLocktime is communicated in the initiation 
>> step, is set to blockheight-6; otherwise set to zero-
>
> I am unsure what is the purpose of this minus 6.
>
> If you fear blockheight disagreements, this is probably a good time to 
> introduce block headers.
> So for example if the acceptor thinks the initiator blockheight is too high, 
> it could challenge the initiator to give block headers from its known 
> blockheight to the initiator blockheight.
> If the acceptor thinks the initiator blockheight is too low, it could provide 
> block headers itself as proof.
> This could be limited so that gross differences in blockheight are outright 
> rejected by the acceptor (it could `error` the temporary channel ID rather 
> than accept it).

Yes, I would just have the initiator specify nLocktime directly, just
like feerate.  If you don't like it, don't contribute to the tx
construction.

> This is SPV, but neither side is actually making or accepting a payment 
> *yet*, just synchronizing clocks, so maybe not as bad as normal SPV.
>
> Massive chain reorgs cannot reduce blockheight, only increase it (else
> the reorg attempt fails in the first place)

This is not quite true, due to difficulty adjustments.  It's true in
practice, however, and not relevant since you'd just have to wait one
more block.

>> - 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 protocol error
>
> I suppose we should define collision to mean "equal in all bits except the 
> lowest bit".

No, literally equal.  i.e. you can only make this error by clashing with
yourself.

Cheers,
Rusty.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[ZmnSCPxj via Lightning-dev]

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, which is what is used to flag utxo reuse. With a PoDLE you're proving 
> that you have a key for a utxo; the verifier checks that the key you say you 
> know does in fact map to controlling the utxo that you say it's attached to. 
> Whether or not you added the utxo to the signature commitment doesn't add 
> anything to the security of the verification.
>
> At worse, it might leak what other utxo that the initiator controls, if they 
> accidentally commit to the wrong utxo and the peer decided to try grinding 
> utxo outpoints on the offchance that one matched.

Right, right, H2 commits to knowledge of the privkey, not a specific UTXO.

I suppose the Right Thing to do if somebody foists address reuse on you would 
be to spend all UTXOs with the same address together.

Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[ZmnSCPxj via Lightning-dev]

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.

Generally over the Internet the presumption is that the server just passively 
lies there in wait, and then a client actively contacts the server to get some 
service.
In terms of Lightning opening protocols, the channel opener is the client, and 
the acceptor is the server.
Similarly, in terms of JoinMarket, the taker is the client, and the maker is 
the server.

Of course the link seems to be very different, am still reading through it.

Regards,
ZmnSCPxj

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[lisa neigut]

> 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
proving that you have a *key* for a utxo; the verifier checks that the key
you say you know does in fact map to controlling the utxo that you say it's
attached to. Whether or not you added the utxo to the signature commitment
doesn't add anything to the security of the verification.

At worse, it might leak what other utxo that the initiator controls, if
they accidentally commit to the wrong utxo and the peer decided to try
grinding utxo outpoints on the offchance that one matched.



On Tue, Feb 11, 2020 at 10:04 PM ZmnSCPxj  wrote:

> 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 signature.
> >
> > Oh that's *much* nicer than calculating a second commitment.
> Verification by any node that's not the intended recipient will fail, as
> they'll use the wrong node_id (their own).
> >
> > It seems unnecessary to me to commit to the utxo, since the pubkey pair
> effectively does that. What's the motivation for including it?
>
> 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.
>
> While address reuse Is Bad, you might not have much control over some wog
> who is supposed to pay you and decides to give you your money in two
> separate UTXOs to the same address.
>
> Regards,
> ZmnSCPxj
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[AdamISZ via Lightning-dev]

> 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 yourselves down 
in any way with attempting to keep compatibility with Joinmarket as-is, unless 
it's trivial to do so ... we will need to pretty much wholesale upgrade our 
protocol at some relatively soon point, ideally straight to schnorr/taproot, or 
if not, at least to native segwit, since coinjoin is a fee-heavy protocol. And 
there's a bunch of legacy stuff (especially in terms of encodings, but other 
stuff too) that will need to change. If you guys end up finding a stronger and 
clearer version of this podle/dleq thing and it ends up being useful, we will 
just tag along (at least, that's likely). And this is why I should not be lazy 
and try to keep up with this conversation!

I wanted to mention something else. Way back, maybe 2 years ago, I remember 
being interested that there *was* actually at least one use-case of DLEQ to 
create blinded tokens in the wild apart from our own. I dug up the link; it's 
really a beautiful idea but it's more based around a client-server model and 
using 'blind signing' (oblivious PRF based, so not old-style RSA or Chaum), but 
it's an easy idea to read and grok I think:

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), 
it's still interesting that they use a DLEQ to prove correctly formed token 
construction, and then prevent 'double spend'. I wouldn't be surprised if there 
is something to learn from this line of thinking.
Cheers,
waxwing

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[ZmnSCPxj via Lightning-dev]

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 signature.
>
> Oh that's *much* nicer than calculating a second commitment. Verification by 
> any node that's not the intended recipient will fail, as they'll use the 
> wrong node_id (their own). 
>
> It seems unnecessary to me to commit to the utxo, since the pubkey pair 
> effectively does that. What's the motivation for including it?

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.

While address reuse Is Bad, you might not have much control over some wog who 
is supposed to pay you and decides to give you your money in two separate UTXOs 
to the same address.

Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[AdamISZ via Lightning-dev]

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 an initiator and a single peer. Otherwise you can enable something 
> I'll call the "pouncing venus-flytrap attack"[1].

Here's some thoughts that may give context to this (excellent) observation:

This issue didn't crop up (well, kinda! I do remember discussion about it) in 
our use case because takers always send out to 5-12 (typically) makers at once, 
and the HP2 only needs to get broadcast by one to stop any reuse.
But whichever way you look at it, it's a very good point! And in LN case, seems 
like a very substantial attack (certainly no question it could be allowed for 2 
party protocol).

In case a brief summary of JM mechanism is helpful, I added some info on the 
the taker-maker conversation at the end of this mail [1].

Second, re:
> ## Mitigation
> Have each initiator provide two commitments: one to the shared/global J
> point and one to a point that is found from the hash of the non-initiating
> node's node_id.[2]

I get the thinking here, and it makes a lot of sense, but I do think it can be 
done more compactly.
If the commitment is H(P2), the opening of the commitment could be altered to 
include the receiving node:

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

As you note, we wouldn't want to ban usage of a H(P2) value based on an 
incorrect opening; we just use that failure to decide to not hand over our utxo 
information (as receiver of the commitment). But unless I missed something, 
doing it the above way is the more logical/compact choice.

Seems like there's a lot of fine nuance here. A malicious counterparty can 
always choose to blacklist. In Joinmarket we accept (because of our stringent 
no-identity policy) some roughness and assume some meaningful level of honest 
participation. A Taker issuing a request to 10 cps hopes that at least some 
number (min 4 by default) will actually respond to an honest request; if say 8 
of 10 do so, he will do the coinjoin with those. That it is brittle or flaky is 
why we allow 3 tries for each qualifying utxo (qualified on age, size), and 
also allow custom insertion of additional utxos (although it's rarely if ever 
needed). It works fine in practice, for now, but it is not watertight; if you 
have overwhelmingly malicious counterparties you are kinda screwed from other 
angles, as well as this one. Meanwhile on the Maker side we're trying to create 
a kind of 'herd immunity'; as long as some few of them are honest, word will 
get out about used commitments which will stop free spam 
 queries,
  at least (but it's not a super strong defence!).


[1] Taker-Maker convo (excerpt); some notes re: commitments/PoDLE.
===
!fill amount, oid, commitment (HP2)
-- this is where a taker sends to each maker an hp2 value. This is the step 
intended to enforce scarcity, and the assumption in JM was always that this 
would basically inevitably get shared. Because there are typically 5-12 makers 
involved, this seemed a reasonably safe assumption.
If the commitment value is already used and thus not valid, it gets broadcast 
immediately. If it's not, it only gets shared as part of the !ioauth step below.

!pubkey key

-- this is just the maker giving an ephemeral key for the encryption

!auth (s, e, u, P, P2)
-- (encrypted) this is the taker opening the above commitment. It's rather 
weird at first sight, because he is opening immediately after committing, with 
apparently no step inbetween; but in fact the implicit intermediate step is the 
broadcast (exactly what is being questioned with 'venus flytrap').

!ioauth maker-utxo-data
-- notice the maker is only sending this utxo data (encrypted of course) after 
proof of ownership of the utxo above.
It's only at this step that the hp2 commitment value is (a) added to the 
maker's local "used up" list, and (b)privmsged to 1  randomly chosen other bots 
in the trading pit, who then pubmsgs it to everyone (and that happens multiple 
times because multiple makers in tx), and they in turn record it as "used".

The mechanism is both not very strong - we use 3 allowed attempts per utxo - 
and imperfect in its "justice"; such commitments can be "used up" by failures 
of one's counterparties. But it does serve to stop trivial global snooping, and 
doesn't cost anything in terms of identity or locked funds, so it has served a 
purpose (we did actually see such attacks before it, and not after it).

I'd also note that in terms of the venus flytrap attack mentioned, there could 
be a small time window between one maker receiving !auth and 

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

[ZmnSCPxj via Lightning-dev]

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

This issue didn't crop up in our use case because takers always send out to 
5-12 (typically) makers at once, and the HP2 only needs to get broadcast by one 
to stop any reuse.
But whichever way you look at it, it's a very good point! And in LN case, seems 
like a very substantial attack (at least from what little I've read so far).

In case a brief summary of JM mechanism is helpful, here's the taker-maker 
conversation:

!fill amount, oid, commitment (HP2)
-- this is where a taker sends to each maker an hp2 value. This is the step 
intended to enforce scarcity, and the assumption in JM was always that this 
would basically inevitably get shared. Because there are typically 5-12 makers 
involved, this seemed a reasonably safe assumption.
If the commitment value is already used and thus not valid, it gets broadcast 
immediately. If it's not, it only gets shared as part of the !ioauth step below.

!pubkey key

-- this is just the maker giving an ephemeral key for the encryption

!auth (s, e, u, P, P2)
-- (encrypted) this is the taker opening the above commitment. It's rather 
weird at first sight, because he is opening immediately after committing, with 
apparently no step inbetween; but in fact the implicit intermediate step is the 
broadcast (exactly what is being questioned with 'venus flytrap').

!ioauth maker-utxo-data
-- notice the maker is only sending this utxo data (encrypted of course) after 
proof of ownership of the utxo above.
It's only at this step that the hp2 commitment value is (a) added to the 
maker's local "used up" list, and (b)privmsged to 1  randomly chosen other bots 
in the trading pit, who then pubmsgs it to everyone (and that happens multiple 
times because multiple makers in tx), and they in turn record it as "used".

The mechanism is both not very strong - we use 3 allowed attempts per utxo - 
and imperfect in its "justice"; such commitments can be "used up" by failures 
of one's counterparties. But it does serve to stop trivial global snooping, and 
doesn't cost anything in terms of identity or locked funds, so it has served a 
purpose (we did actually see such attacks before it, and not after it).

I'd also note that in terms of the venus flytrap attack mentioned, there could 
be a small time window between one maker receiving !auth and at least one other 
honest maker getting to broadcast step at !ioauth; while I don't think that's 
very practical in our use case, it is for sure a theoretical concern and 
removing it could be either slightly, or extremely, important in another use 
case.

I'll have a look at this new idea related to node-id and get back to you on 
that. Thanks for this analysis and investigation, it's a very interesting area.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[ZmnSCPxj via Lightning-dev]

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 from mitigates the flood we talked about 
> with ZmnSCPxj.
> However I don't see how the number of utxos in the mempool is useful here, as 
> you cannot distinguish which PoDLE is the real one out of the load you are 
> receiving in case of a flood ?

No idea either, but if we limit accepted `node_id`s to those that we have seen 
in a `node_announcement` before, then we ride on the fact that 
`node_announcement` is costly in the sense that somebody has to allocate at 
least some small amount of funds to a channel that is visible onchain, because 
`node_announcement` requires a `channel_announcement` with an anchored channel.

Then if nodes on the network can just send PoDLE gossip that they did not sign 
themselves, but are signed by *some* node that was `node_announcement`ed 
before, we can identify those nodes that are spamming a lot of their own signed 
PoDLE gossip, and rate-limit those.

It is likely that announced nodes are the ones who will have such attack 
attempts performed on them, so they are in the best position to inform others 
of such attempts and are the most likely to have such data.

At some point we probably also need to have set reconciliation for these as 
well.

Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[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 initiating message (in the case of open channel, this would be 
> `open_channel2`) is extended to include an 'H2' field in its TLV, a 32-byte 
> hash commitment to the P2 key.
> - Only one H2 commitment is required.
> - The `tx_add_input` message, as specified previously, is extended to an 
> include a TLV type. This must be present on the input addition that 
> corresponds with the UTXO used for the originally transmitted commitment
> - The non-initiator SHOULD wait to send any `tx_add_input` messages of their 
> own until after receiving a `tx_add_input` message with a valid PoDLE TLV 
> extension.
> 

> 1. tlvs: `add_input_tlvs`
> 2. types:
>     1. type: 1 (`proof_of_dle`)
>     2. data:
>         *[`64*byte`:`s||e`]
>         *[`33*byte`:pubkey`]
>         *[`33*byte`:pubkey2`]
> 

> - If the proof is incorrect, the non-initiator MAY fail the transaction 
> collaboration or respond with `tx_complete`. There is no need for them to 
> publish the PoDLE.
> - If the proof is correct, the non-initiator verifies that the commitment 
> (hash of pubkey2) has not been communicated to them via gossip.
> - If the proof is not in their gossip store, the transaction collaboration 
> continues. It is considered 'safe' for the non-initiator to send 
> `tx_add_input` to their peer.
> - If the proof IS in their gossip store, the transaction collaboration SHOULD 
> reply with `tx_complete`. It is considered 'unsafe' for the non-initiator to 
> send `tx_add_input`. (This allows errored/erroring initiators to use 
> blacklisted utxos, however it prevents them from privy to any other nodes' 
> UTXO set.)

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 initiator MUST NOT remove the committed to UTXO from the collaboration 
> set.
> 

> - If the transaction collaboration fails/is errored by the initiator,
>     - the non-initiator SHOULD broadcast the original PoDLE commitment to the 
> gossip network.
>     - the non-initiator MAY delay broadcast to allow the initiating node to 
> re-attempt the open.
> 

> The gossip message for a PoDLE blacklist entry is as follows:
> 

> 1. type: 259 (`podle_blacklist`)
> 2. data: 
>     *[`signature`:`signature`]
>     *[`32*byte`:`H2`]
>     *[`point`:`node_id`]
>     *[`u32`:`timestamp`]
> 

> Note that the `node_id` is the id of the node that signs (and broadcasts) the 
> blacklisted PoDLE. h/t to ZmnSCPxj for the gossip construction.
> The timestamp is added as a convenience for peers to trim/discard blacklist 
> participants as they wish depending on time/staleness.
> 

> ## Some Notes:
> - The JoinMarket protocol allows nodes to use any of a range of secondary 
> points for J. Since the lightning version of this allows blacklisted UTXOs to 
> still open channels, albeit without participation from the peer, it seems 
> unnecessary to allow for more than one valid J point. I'd propose fixing the 
> J the same zero-index point used by JoinMarket. This reduces the number of 
> valid H2's that are available for any given utxo set, while also keeping 
> blacklisted H2's compatible with the blacklist set generated by JoinMarket 
> implementations.
> - The blacklist originates from the 'non-initiating' peer, and does not 
> reveal the offending node's id. 
> - Assuming that every node honestly participates in the blacklist, only 
> verified H2's will be submitted to the blacklist
> - A malicious non-initiator can only prevent an honest initiator from using 
> the committed UTXO for collaborative transactions; they won't prevent them 
> from successfully initiating a one-sided transaction with honest peers.
> - Only nodes that have at least one public channel will be able to contribute 
> to the public PoDLE blacklist. This means it's possible for a malicious 
> initiator to grief non-public nodes without much consequence, however this 
> requires the ability to send inbound messages to private nodes, i.e. more 
> likely for a close or splice interaction.
> - As ZmnSCPxj has pointed out elsewhere, a malicious peer could broadcast 
> junk H2's; it is acceptable to rate-limit the number of PoDLE blacklists 
> generated by a peer.peer
> - It is possible for a malicious peer to fail to relay their `H2` entries in 
> the blacklisted gossip set.
> - Duplicate H2 gossip should replace older timestamped versions.
> - Elsewhere we've had a discussion/concern over floods of PoDLE blacklist 
> messages. It's possible for gossip message floods to originate from a 
> malicious peer; they also might signal an ongoing probe attempt. Given a 
> timestamp and a rough measure of the number of utxos' 

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

[lisa neigut]

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
because they sit in wait for victims; pouncing because the venus-flytrap
then attacks other nodes using the provided fly/utxo bait.

## The Attack
A malicious node sits and waits until another, honest, node initiates an
open with them. They wait until the honest initiator has sent them the
commitment and utxo proof. They then use the provided, non-blacklisted utxo
and commitment proof to attempt to open a channel with as many other nodes
as possible, simultaneously. They may either fail to respond or not fail
the original channel open. They fail every other open attempt,
simultaneously. Each of the nodes they've griefed will blacklist the
provided UTXO; the honest initiator has now had their utxo blacklisted.

## Mitigation
Have each initiator provide two commitments: one to the shared/global J
point and one to a point that is found from the hash of the non-initiating
node's node_id.[2]

The global-point commitment is the one that is blacklisted; the node_id's
commitment prevents the other party from being able to re-use a commitment
in another channel, as they'll be unable to produce a valid commitment to
the point derived from the node_id of their victim (so the victim will know
the commitment has been re-used).

This has implications for 'multi-channel opens', in that any node
initiating an open MUST provide at least one utxo of their own. This seems
like an acceptable limitation, imo.

The protocol adjustments required for this are :

- Add a second commitment to the TLV of `open_channel2`; two H2's, one for
the 'global J' and one for the 'nodes J', with the global point commitment
always appearing first.
- The TLV type for the `tx_add_input` for the 'committed utxo' will now
include an array of two `proof of dle's`, in commitment hash order.

1. tlvs: `add_input_tlvs`
2. types:
1. type: 1 (`proof_of_dle_array`)
2. data:
*[`2*proof_of_dle`]

1. subtype (`proof_of_dle`)
*[`64*byte`:`s||e`]
*[`33*byte`:pubkey`]
*[`33*byte`:pubkey2`]

A node that provides a valid global point but an invalid 'local point'
commitment should be immediately errored on and potentially blacklisted.
A failure of this type should *not* result in a blacklist of the global
commitment.

[1] There's probably a better analogy here, but it's escaping me at the
moment.
[2] We reuse JoinMarket's NUMs point generation idea of appending a counter
to a hash until a valid positive-public key point is found, but without the
index.

On Mon, Feb 10, 2020 at 5:11 PM lisa neigut  wrote:

> 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 32-byte
> hash commitment to the P2 key.
> - Only one H2 commitment is required.
> - The `tx_add_input` message, as specified previously, is extended to an
> include a TLV type. This must be present on the input addition that
> corresponds with the UTXO used for the originally transmitted commitment
> - The non-initiator SHOULD wait to send any `tx_add_input` messages of
> their own until after receiving a `tx_add_input` message with a valid PoDLE
> TLV extension.
>
> 1. tlvs: `add_input_tlvs`
> 2. types:
> 1. type: 1 (`proof_of_dle`)
> 2. data:
> *[`64*byte`:`s||e`]
> *[`33*byte`:pubkey`]
> *[`33*byte`:pubkey2`]
>
> - If the proof is incorrect, the non-initiator MAY fail the transaction
> collaboration or respond with `tx_complete`. There is no need for them to
> publish the PoDLE.
> - If the proof is correct, the non-initiator verifies that the commitment
> (hash of pubkey2) has not been communicated to them via gossip.
> - If the proof is not in their gossip store, the transaction collaboration
> continues. It is considered 'safe' for the non-initiator to send
> `tx_add_input` to their peer.
> - If the proof IS in their gossip store, the transaction collaboration
> SHOULD reply with `tx_complete`. It is considered 'unsafe' for the
> non-initiator to send `tx_add_input`. (This allows errored/erroring
> initiators to use blacklisted utxos, however it prevents them from privy to
> any other nodes' UTXO set.)
> - The initiator MUST NOT remove the committed to UTXO from the
> collaboration set.
>
> - If the transaction collaboration fails/is errored by the initiator,
> - the non-initiator SHOULD broadcast the original PoDLE commitment to
> the gossip network.
> - the non-initiator MAY delay broadcast to allow the initiating node
> to re-attempt the open.
>
> The gossip message for a PoDLE 

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

[lisa neigut]

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 32-byte
hash commitment to the P2 key.
- Only one H2 commitment is required.
- The `tx_add_input` message, as specified previously, is extended to an
include a TLV type. This must be present on the input addition that
corresponds with the UTXO used for the originally transmitted commitment
- The non-initiator SHOULD wait to send any `tx_add_input` messages of
their own until after receiving a `tx_add_input` message with a valid PoDLE
TLV extension.

1. tlvs: `add_input_tlvs`
2. types:
1. type: 1 (`proof_of_dle`)
2. data:
*[`64*byte`:`s||e`]
*[`33*byte`:pubkey`]
*[`33*byte`:pubkey2`]

- If the proof is incorrect, the non-initiator MAY fail the transaction
collaboration or respond with `tx_complete`. There is no need for them to
publish the PoDLE.
- If the proof is correct, the non-initiator verifies that the commitment
(hash of pubkey2) has not been communicated to them via gossip.
- If the proof is not in their gossip store, the transaction collaboration
continues. It is considered 'safe' for the non-initiator to send
`tx_add_input` to their peer.
- If the proof IS in their gossip store, the transaction collaboration
SHOULD reply with `tx_complete`. It is considered 'unsafe' for the
non-initiator to send `tx_add_input`. (This allows errored/erroring
initiators to use blacklisted utxos, however it prevents them from privy to
any other nodes' UTXO set.)
- The initiator MUST NOT remove the committed to UTXO from the
collaboration set.

- If the transaction collaboration fails/is errored by the initiator,
- the non-initiator SHOULD broadcast the original PoDLE commitment to
the gossip network.
- the non-initiator MAY delay broadcast to allow the initiating node to
re-attempt the open.

The gossip message for a PoDLE blacklist entry is as follows:

1. type: 259 (`podle_blacklist`)
2. data:
*[`signature`:`signature`]
*[`32*byte`:`H2`]
*[`point`:`node_id`]
*[`u32`:`timestamp`]

Note that the `node_id` is the id of the node that signs (and broadcasts)
the blacklisted PoDLE. h/t to ZmnSCPxj for the gossip construction.
The timestamp is added as a convenience for peers to trim/discard blacklist
participants as they wish depending on time/staleness.

## Some Notes:
- The JoinMarket protocol allows nodes to use any of a range of secondary
points for J. Since the lightning version of this allows blacklisted UTXOs
to still open channels, albeit without participation from the peer, it
seems unnecessary to allow for more than one valid J point. I'd propose
fixing the J the same zero-index point used by JoinMarket. This reduces the
number of valid H2's that are available for any given utxo set, while also
keeping blacklisted H2's compatible with the blacklist set generated by
JoinMarket implementations.
- The blacklist originates from the 'non-initiating' peer, and does not
reveal the offending node's id.
- Assuming that every node honestly participates in the blacklist, only
verified H2's will be submitted to the blacklist
- A malicious non-initiator can only prevent an honest initiator from using
the committed UTXO for collaborative transactions; they won't prevent them
from successfully initiating a one-sided transaction with honest peers.
- Only nodes that have at least one public channel will be able to
contribute to the public PoDLE blacklist. This means it's possible for a
malicious initiator to grief non-public nodes without much consequence,
however this requires the ability to send inbound messages to private
nodes, i.e. more likely for a close or splice interaction.
- As ZmnSCPxj has pointed out elsewhere, a malicious peer could broadcast
junk H2's; it is acceptable to rate-limit the number of PoDLE blacklists
generated by a peer.peer
- It is possible for a malicious peer to fail to relay their `H2` entries
in the blacklisted gossip set.
- Duplicate H2 gossip should replace older timestamped versions.
- Elsewhere we've had a discussion/concern over floods of PoDLE blacklist
messages. It's possible for gossip message floods to originate from a
malicious peer; they also might signal an ongoing probe attempt. Given a
timestamp and a rough measure of the number of utxos' currently outstanding
in the mempool, however, it should be possible to distinguish the two.

## Open Questions:
- Should PoDLE be required for every collaborative transaction (opens,
splices + closes), or only for opens? It seems reasonable to limit them
just to opens, as for all others you'll already have a shared UTXO with the
peer.
- Is fixing the generator point too restrictive? JoinMarket allows for a
range of acceptable NUMS (J) points (up to 256). The smaller the pool of
eligible J's, the 

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

[lisa neigut]

> 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 others, and would be a
reliable indicator that the transaction is a Lightning channel funding
attempt.

Ah good point. This can be mitigated by setting the acceptable range up to
100 then, matching the behavior of bitcoind.






On Thu, Feb 6, 2020 at 6:23 PM ZmnSCPxj  wrote:

> 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, so
> I'm not sure this accomplishes this goal.  I'm not sure how bitcoind
> handles the mempool in the case of the 'best block' moving to another tip,
> the goal of setting it to -6 is to avoid the funding transaction being
> evicted.
>
> My understanding is that it rewinds the abandoned tip, putting the
> transactions in those blocks back into its local mempool (which may lead to
> evictions if the mempool gets full), all the way to the branch-off point,
> then it re-adds blocks back to the new tip (which can lead to removals from
> the mempool, if transactions in the block spend the same UTXOs (or *are*
> the same transactions) as transactions in the mempool).
> The main effect is that there could be suddenly higher fee pressure for
> the transactions in the reorged-away blocks (because of possible mempool
> congestion if the longer chainsplit has fewer transactions per block), but
> that is why the dual-funding protocol has RBF built-in right?
>
> Setting blockheight - 6 also increases the incentive of potential
> deliberate reorgers to actually perform a reorg attack, because the
> transaction you just added is valid for earlier blocks that the reorger
> wants to rewrite.
> This is a bad thing, because you want your funding txout to be confirmed,
> not have parts of global hashpower contemplating reorgs and delaying your
> confirmations even more.
>
>
> >
> > In practice, setting the locktime back a few blocks makes the funding
> transaction eligible for inclusion in any of the previous six blocks, so in
> case of a reorg there's a higher probability it will have been included in
> the reorganization. In other words, it enables fee-sniping for up to 6
> blocks in the hopes that any 'eligible' re-org includes the funding
> transaction (the short channel id will change, but otherwise the channel
> open will be the same).
> >
> > On second thought, this doesn't seem like something that we should
> include at the protocol level; if a peer wanted to 'allow fee-sniping for
> up to X blocks', then they'd simply relay the "blocktip" that they're using
> for the nLocktime to be at the depth they'd desire. Though it might be
> worth imposing a limit as to how far back in the past a peer can allow
> fee-sniping for... no more than 6 blocks from our current tip seems
> reasonable. (This would then limit the 'acceptable range' for an offset of
> an initiator to 5, as your peer may be off from your tip by one.)
> >
> > On that note, I believe bitcoind fuzzes the nLocktime value to obfuscate
> exactly what blockheight the outgoing transaction was composed / broadcast
> at, which is probably something we should encourage in lightning
> implementations as well.
>
> 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
> others, and would be a reliable indicator that the transaction is a
> Lightning channel funding attempt.
> The fuzzing may not be big enough to cover that, as there is a 10% chance
> to fuzz and about 1% subsequent chance (total 0.1% chance) that Bitcoin ore
> will put a transaction at blockheight - 6 (as opposed to the 99 other
> possibilities: blockheight - 0 to blockheight - 99 inclusive).
> So once more than 0.1% of onchain transactions are Lightning
> dual-fundings, an analyst has > 50% chance of correctly betting that a
> blockheight - 5 transaction (yes, - 5, because a transaction can typically
> be added only on the next block) is a Lightning funding.
>
>
> You are better off with blockheight, possibly with SPV-header-chain-proofs
> if one side or the other thinks the blockheight has changed since one side
> or the other proposed it.
>
>
> Regards,
> ZmnSCPxj
>
> >
> > On Wed, Feb 5, 2020 at 8:25 PM ZmnSCPxj  wrote:
> >
> > > Good morning niftynei,
> > >
> > > > Rusty had some suggestions about how to improve the 

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

[ZmnSCPxj via Lightning-dev]

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, so I'm 
> not sure this accomplishes this goal.  I'm not sure how bitcoind handles the 
> mempool in the case of the 'best block' moving to another tip, the goal of 
> setting it to -6 is to avoid the funding transaction being evicted. 

My understanding is that it rewinds the abandoned tip, putting the transactions 
in those blocks back into its local mempool (which may lead to evictions if the 
mempool gets full), all the way to the branch-off point, then it re-adds blocks 
back to the new tip (which can lead to removals from the mempool, if 
transactions in the block spend the same UTXOs (or *are* the same transactions) 
as transactions in the mempool).
The main effect is that there could be suddenly higher fee pressure for the 
transactions in the reorged-away blocks (because of possible mempool congestion 
if the longer chainsplit has fewer transactions per block), but that is why the 
dual-funding protocol has RBF built-in right?

Setting blockheight - 6 also increases the incentive of potential deliberate 
reorgers to actually perform a reorg attack, because the transaction you just 
added is valid for earlier blocks that the reorger wants to rewrite.
This is a bad thing, because you want your funding txout to be confirmed, not 
have parts of global hashpower contemplating reorgs and delaying your 
confirmations even more.


>
> In practice, setting the locktime back a few blocks makes the funding 
> transaction eligible for inclusion in any of the previous six blocks, so in 
> case of a reorg there's a higher probability it will have been included in 
> the reorganization. In other words, it enables fee-sniping for up to 6 blocks 
> in the hopes that any 'eligible' re-org includes the funding transaction (the 
> short channel id will change, but otherwise the channel open will be the 
> same). 
>
> On second thought, this doesn't seem like something that we should include at 
> the protocol level; if a peer wanted to 'allow fee-sniping for up to X 
> blocks', then they'd simply relay the "blocktip" that they're using for the 
> nLocktime to be at the depth they'd desire. Though it might be worth imposing 
> a limit as to how far back in the past a peer can allow fee-sniping for... no 
> more than 6 blocks from our current tip seems reasonable. (This would then 
> limit the 'acceptable range' for an offset of an initiator to 5, as your peer 
> may be off from your tip by one.)
>
> On that note, I believe bitcoind fuzzes the nLocktime value to obfuscate 
> exactly what blockheight the outgoing transaction was composed / broadcast 
> at, which is probably something we should encourage in lightning 
> implementations as well.

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 others, and would be a 
reliable indicator that the transaction is a Lightning channel funding attempt.
The fuzzing may not be big enough to cover that, as there is a 10% chance to 
fuzz and about 1% subsequent chance (total 0.1% chance) that Bitcoin ore will 
put a transaction at blockheight - 6 (as opposed to the 99 other possibilities: 
blockheight - 0 to blockheight - 99 inclusive).
So once more than 0.1% of onchain transactions are Lightning dual-fundings, an 
analyst has > 50% chance of correctly betting that a blockheight - 5 
transaction (yes, - 5, because a transaction can typically be added only on the 
next block) is a Lightning funding.


You are better off with blockheight, possibly with SPV-header-chain-proofs if 
one side or the other thinks the blockheight has changed since one side or the 
other proposed it.


Regards,
ZmnSCPxj

>
> On Wed, Feb 5, 2020 at 8:25 PM ZmnSCPxj  wrote:
>
> > 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 during construction (replacing current usage of 
> > > BIP69). Inputs can be shared amongst peers by flipping the bottom bit of 
> > > the serial_id before relaying them to another peer (as your own).
> >
> > What happens if the initiator deliberately provides serial IDs 0x1, 0x3, 
> >  while the acceptor naively provides serial IDs from `/dev/urandom`?
> >
> > Then the balance of probability is that the initiator inputs and outputs 
> > are sorted before the acceptor.
> > Now, 

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

[lisa neigut]

> 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 accomplishes this goal.  I'm not sure how bitcoind
handles the mempool in the case of the 'best block' moving to another tip,
the goal of setting it to -6 is to avoid the funding transaction being
evicted.

In practice, setting the locktime back a few blocks makes the funding
transaction eligible for inclusion in any of the previous six blocks, so in
case of a reorg there's a higher probability it will have been included in
the reorganization. In other words, it enables fee-sniping for up to 6
blocks in the hopes that any 'eligible' re-org includes the funding
transaction (the short channel id will change, but otherwise the channel
open will be the same).

On second thought, this doesn't seem like something that we should include
at the protocol level; if a peer wanted to 'allow fee-sniping for up to X
blocks', then they'd simply relay the "blocktip" that they're using for the
nLocktime to be at the depth they'd desire. Though it might be worth
imposing a limit as to how far back in the past a peer can allow
fee-sniping for... no more than 6 blocks from our current tip seems
reasonable. (This would then limit the 'acceptable range' for an offset of
an initiator to 5, as your peer may be off from your tip by one.)

On that note, I believe bitcoind fuzzes the nLocktime value to obfuscate
exactly what blockheight the outgoing transaction was composed / broadcast
at, which is probably something we should encourage in lightning
implementations as well.



On Wed, Feb 5, 2020 at 8:25 PM ZmnSCPxj  wrote:

> 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 during construction (replacing current usage of BIP69).
> Inputs can be shared amongst peers by flipping the bottom bit of the
> serial_id before relaying them to another peer (as your own).
>
> What happens if the initiator deliberately provides serial IDs 0x1, 0x3,
>  while the acceptor naively provides serial IDs from `/dev/urandom`?
>
> Then the balance of probability is that the initiator inputs and outputs
> are sorted before the acceptor.
> Now, this is probably not an issue, since the initiator and acceptor both
> know which inputs and outputs are theirs and not theirs, so they could just
> reveal this information to anyone, so an actor providing such lousy serial
> IDs is just hurting its own privacy relative to blockchain analysts, so
> probably will not happen in practice.
>
> My initial reaction was to propose adding a secret-sharing round where the
> resulting key is XORed to each serial ID before sorting by the XORed serial
> ID, but this might be too overweight, and again the initiator is only
> hurting its own privacy, and the two participants already know whose money
> is whose anyway
>
> >
> > See below for details.
> >
> > > 1. type:   440 `tx_add_input`
> > >
> > > 2. data:
> > >
> > > * [`32*byte`:`channel_identifier`]
> >
> > * [`32*byte`:``serial_id`]
> >
> > Add a serial id.
> >
> > Each input addition must have a unique serial id.
> >
> > No addition may have a repeated id number.
> >
> > The initiator's serial id's must be odd. The non-initiator's serial id's
> must be even.
> >
> > Serial ids are used as sorting heuristic for input ordering in final
> transaction, replaces BIP69
> >
> >
> > > * [`u64`:`sats`]
> > >
> > > * [`sha256`:`prevtx_txid`]
> > >
> > > * [`u32`:`prevtx_vout`]
> > >
> > > * [`u16`:`prevtx_scriptpubkey_len`]
> > >
> > > * [`prevtx_scriptpubkey_len*byte`:`prevtx_scriptpubkey`]
> > >
> > > * [`u16`:`max_witness_len`]
> > >
> > > * [`u16`:`scriptlen`]
> > >
> > > * [`scriptlen*byte`:`script`]
> >
> > Removes the signal_rbf; everything will be flagged as RBF eligible.
> (This makes verifying RBF eligibility during a RBF round simpler.)
>
> Yes. Ish.
> RBF and privacy do not work well together unfortunately.
> This is still initiator-pays, right?
>
>
> > > 1. subtype: `witness_element`
> > >
> > > 2. data:
> > >
> > > * [`u16`:`len`]
> > >
> > > * [`len*byte`:`witness`]
> > >
> > > ## General Notes
> > >
> > > - All output scripts must be standard
> > >
> > > - nLocktime is always set to 0x
> >
> > - If a blockheight to be used as nLocktime is communicated in the
> initiation step, is set to blockheight-6; otherwise set to zero-
>
> I am unsure what is the purpose of this minus 6.
>
> If you fear blockheight disagreements, this is probably a good time to
> introduce block headers.
> So for example if the acceptor 

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

[ZmnSCPxj via Lightning-dev]

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 during construction (replacing current usage of BIP69). Inputs can be 
> shared amongst peers by flipping the bottom bit of the serial_id before 
> relaying them to another peer (as your own).

What happens if the initiator deliberately provides serial IDs 0x1, 0x3,  
while the acceptor naively provides serial IDs from `/dev/urandom`?

Then the balance of probability is that the initiator inputs and outputs are 
sorted before the acceptor.
Now, this is probably not an issue, since the initiator and acceptor both know 
which inputs and outputs are theirs and not theirs, so they could just reveal 
this information to anyone, so an actor providing such lousy serial IDs is just 
hurting its own privacy relative to blockchain analysts, so probably will not 
happen in practice.

My initial reaction was to propose adding a secret-sharing round where the 
resulting key is XORed to each serial ID before sorting by the XORed serial ID, 
but this might be too overweight, and again the initiator is only hurting its 
own privacy, and the two participants already know whose money is whose 
anyway

>
> See below for details.
>
> > 1. type:   440 `tx_add_input`
> >
> > 2. data:
> >
> > * [`32*byte`:`channel_identifier`]
>
>         * [`32*byte`:``serial_id`] 
>
> Add a serial id.
>
> Each input addition must have a unique serial id.
>
> No addition may have a repeated id number.
>
> The initiator's serial id's must be odd. The non-initiator's serial id's must 
> be even.
>
> Serial ids are used as sorting heuristic for input ordering in final 
> transaction, replaces BIP69
>  
>
> > * [`u64`:`sats`]
> >
> > * [`sha256`:`prevtx_txid`]
> >
> > * [`u32`:`prevtx_vout`]
> >
> > * [`u16`:`prevtx_scriptpubkey_len`]
> >
> > * [`prevtx_scriptpubkey_len*byte`:`prevtx_scriptpubkey`]
> >
> > * [`u16`:`max_witness_len`]
> >
> > * [`u16`:`scriptlen`]
> >
> > * [`scriptlen*byte`:`script`]
>
> Removes the signal_rbf; everything will be flagged as RBF eligible. (This 
> makes verifying RBF eligibility during a RBF round simpler.)

Yes. Ish.
RBF and privacy do not work well together unfortunately.
This is still initiator-pays, right?


> > 1. subtype: `witness_element`
> >
> > 2. data:
> >
> > * [`u16`:`len`]
> >
> > * [`len*byte`:`witness`]
> >
> > ## General Notes
> >
> > - All output scripts must be standard
> >
> > - nLocktime is always set to 0x
>
> - If a blockheight to be used as nLocktime is communicated in the initiation 
> step, is set to blockheight-6; otherwise set to zero-

I am unsure what is the purpose of this minus 6.

If you fear blockheight disagreements, this is probably a good time to 
introduce block headers.
So for example if the acceptor thinks the initiator blockheight is too high, it 
could challenge the initiator to give block headers from its known blockheight 
to the initiator blockheight.
If the acceptor thinks the initiator blockheight is too low, it could provide 
block headers itself as proof.
This could be limited so that gross differences in blockheight are outright 
rejected by the acceptor (it could `error` the temporary channel ID rather than 
accept it).

This is SPV, but neither side is actually making or accepting a payment *yet*, 
just synchronizing clocks, so maybe not as bad as normal SPV.

Massive chain reorgs cannot reduce blockheight, only increase it (else the 
reorg attempt fails in the first place) so there must still exist at least one 
chain(split) with the highest known blockheight already given a 
proof-of-header-chain, and all you really need is some mining activity on top 
of *one* split that confirms your funding transaction.

If it is not because of blockheight disagreements or massive chain reorgs, what 
is the purpose of `blockheight - 6`?



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

I suppose we should define collision to mean "equal in all bits except the 
lowest bit".

Regards,
ZmnSCPxj

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[lisa neigut]

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 usage of BIP69).
Inputs can be shared amongst peers by flipping the bottom bit of the
serial_id before relaying them to another peer (as your own).

See below for details.


1. type:   440 `tx_add_input`
>
> 2. data:
>
> * [`32*byte`:`channel_identifier`]
>
* [`32*byte`:``serial_id`]

Add a serial id.

Each input addition must have a unique serial id.

No addition may have a repeated id number.

The initiator's serial id's must be odd. The non-initiator's serial id's
must be even.
Serial ids are used as sorting heuristic for input ordering in final
transaction, replaces BIP69


* [`u64`:`sats`]
>
> * [`sha256`:`prevtx_txid`]
>
> * [`u32`:`prevtx_vout`]
>
> * [`u16`:`prevtx_scriptpubkey_len`]
>
> * [`prevtx_scriptpubkey_len*byte`:`prevtx_scriptpubkey`]
>
> * [`u16`:`max_witness_len`]
>
> * [`u16`:`scriptlen`]
>
> * [`scriptlen*byte`:`script`]
>
> Removes the signal_rbf; everything will be flagged as RBF eligible. (This
makes verifying RBF eligibility during a RBF round simpler.)


> 1. type: 442 `tx_add_output`
>
> 2. data:
>
> * [`32*byte`:`channel_identifier`]
>
* [`16*byte`:`serial_id`]

Add a serial id. Same rules as for inputs, but a distinct counter set is
used.
Used for ordering the transactions’ outputs, replacing BIP69



> * [`u64`:`sats`]
>
> * [`u16`:`scriptlen`]
>
> * [`scriptlen*byte`:`script`]
>
> 1. type: 444 `tx_remove_input`
>
> 2. data:
>
> * [`32*byte`:`channel_identifier`]
>
* [`16*byte`:`serial_id`]


Input to remove identified by the serial id, not txid and index.



>
> 1. type: 446 `tx_remove_output`
>
> 2. data:
>
> * [`32*byte`:`channel_identifier`]
>
* [`16*byte`:`serial_id]

Output to remove identified by the serial id, not output script and amount.



> 1. type: 448 `tx_complete`
>
> 2. data:
>
> * [`32*byte`:`channel_identifier`]
>

Total counts removed from tx_complete. The txid exchanged in the `tx_sigs`
will serves as a checksum for the transaction.


> 1. type:  448 `tx_sigs`
>
> 2. data:
>
> * [`channel_id`:`channel_identifier`]
>
> * [`u16`:`num_witnesses`]
>
> * [`num_witnesses*witness_stack`:`witness_stack`]
>
> 1. subtype: `witness_stack`
>
> 2. data:
>
* [`u16`:`num_input_witness`]
>
> * [`num_input_witness*witness_element`:`witness_element`]
>

prev_out and prev_txid are removed; witnesses ordered implicitly by
serial_id.


> 1. subtype: `witness_element`
>
> 2. data:
>
> * [`u16`:`len`]
>
> * [`len*byte`:`witness`]
>
>
>
> ## General Notes
>
> - All output scripts must be standard
>
> - nLocktime is always set to 0x
>
- If a blockheight to be used as nLocktime is communicated in the
initiation step, is set to blockheight-6; otherwise set to zero-
- 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 protocol error
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[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 response where niftynei proposed to accord on 
setting it to tip-6 so that reorg is not a problem (or if it is, there are 
bigger).
\ Original Message 
On Jan 30, 2020, 19:45, Antoine Riard < antoine.ri...@gmail.com> wrote:

>
>
>
> > 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 mempool but that's fine if it does from the initiator
>
> one.
>
>
>
> Or are you talking about the commitment tx (different issue and there is
>
>
> broader privacy leaks there) ?
>
> > Darosior ( i'll stick with my pseudo, first names definitely don't have 
> > enough entropy :-) )
>
>
>
> Ahaha yeah this pseudo-random-name-generator is definitely not trustworthy :p
>
>
>
>
>
>
>
>
> Le jeu. 30 janv. 2020 à 13:19, darosior 
> <[daros...@protonmail.com][darosior_protonmail.com]> a écrit :
>
>
> > 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 
> > On Jan 30, 2020, 19:09, Antoine Riard < 
> > [antoine.ri...@gmail.com][antoine.riard_gmail.com]> wrote:
> >
> > >
> > >
> > >
> > > 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 IMO that's
> > > fine if at least the initiator is able to do so. We are requiring peers
> > >
> > >
> > > to be weakly in sync before operating channel anyway (\`funding\_locked\`
> > >
> > >
> > > exchange).
> > >
> > >
> > >
> > >
> > >
> > > Funding\_tx can already be drop from mempool for others
> > >
> > >
> > > reasons like mempool shrinks or expiry so broadcaster
> > >
> > >
> > > should always be ready to re-send it or bump feerate.
> > >
> > >
> > >
> > > Or are you describing another issue ?
> > >
> > >
> > >
> > >
> > >
> > > Le jeu. 30 janv. 2020 à 04:06, darosior 
> > > <[daros...@protonmail.com][darosior_protonmail.com]> a écrit :
> > >
> > >
> > > > 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 of reorg the funding tx (now non-final) would be 
> > > > dropped from mempool ? But you could set nLockTime to, say, tip - 6. 
> > > > (niftynei)
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Antoine
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > \ Original Message 
> > > > On Jan 30, 2020, 01:21, Antoine Riard < 
> > > > [antoine.ri...@gmail.com][antoine.riard_gmail.com]> wrote:
> > > >
> > > > >
> > > > >
> > > > >
> > > > > 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 the current proposal hold, if you are a 
> > > > > bit more
> > > > >
> > > > >
> > > > > tolerant and bridge peer don't send a tx\_complete before receiving 
> > > > > ones
> > > > >
> > > > >
> > > > > from all its peers.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > What about transactions format ? I think we should coordinate with 
> > > > > Coinjoin
> > > > >
> > > > >
> > > > > people to converge to a common one to avoid leaking protocol usage 
> > > > > when
> > > > > we can hinder under Taproot. Like setting the nLocktime or sorting 
> > > > > inputs
> > > > >
> > > > >
> > > > 

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

[ZmnSCPxj via Lightning-dev]

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 
> https://gist.github.com/AdamISZ/9cbba5e9408d23813ca8#defence-2-committing-to-a-utxo-in-publicplaintext-at-the-start-of-the-handshake
>  and https://joinmarket.me/blog/blog/poodle/ uses Schnorr signature. Can we 
> use this protocol with ECDSA ?

I cannot really grok the exact mathematics of ECDSA, and the signing scheme for 
PoDLE is not *exactly* Schnorr but certainly uses the same schema.

It looks to me that the DLEQ proof is based on Fiat-Shamir (as Schnorr signing 
is), though you might do better from an answer from an actual cryptographer.

In any case it is not used onchain anyway, and it is not going to be exactly 
the same as normal ECDSA signing so code reuse is still unlikely.


> I'm now thinking about how this could be integrated into niftynei's work on 
> the dual-funded channel proposal. The PoDLE broadcast protocol seems to be 
> the bigger part.
>
> Imagining the size of the monster PR if PoDLEs ever get integrated

Another wrinkle is that, PoDLE needs to be exchanged if the acceptor wants to 
add its own funds.
If the opener offers to open a channel but the acceptor is not interested in 
revealing its own funds, then the opener need not reveal PoDLE of its UTXOs.

It seems to me that individual PoDLEs are small enough (32 bytes, `h(P2)` is 
all you need for the commitment, the signature-like thing is part of the 
opening, if my understanding is correct) that a simple gossip protocol might 
work.


Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[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-start-of-the-handshake
 and https://joinmarket.me/blog/blog/poodle/ uses Schnorr signature. Can we use 
this protocol with ECDSA ?

I'm now thinking about how this could be integrated into niftynei's work on the 
dual-funded channel proposal. The PoDLE broadcast protocol seems to be the 
bigger part.

*Imagining the size of the monster PR if PoDLEs ever get integrated*
Regards,
Darosior

‐‐‐ Original Message ‐‐‐
Le vendredi, janvier 31, 2020 12:31 AM, ZmnSCPxj  a 
écrit :

> Good morning darosior, ariard, niftynei, and list,
> 

> > We could also consider PoDLE as used in JoinMarket, which solves a similar 
> > problem.
> > https://gist.github.com/AdamISZ/9cbba5e9408d23813ca8#defence-2-committing-to-a-utxo-in-publicplaintext-at-the-start-of-the-handshake
> > Basically, a PoDLE commits to a UTXO, without being trivially grindable 
> > from the UTXO set and also including a proof that the creator of the PoDLE 
> > knows the secret key behind it.
> > It can later be opened to reveal which UTXO the opener allocated.
> > If the opener aborts (i.e. does not provide its signatures to the funding 
> > transaction) then the acceptor can gossip the UTXO and the revealed PoDLE 
> > as well to the rest of Lightning, so that the opener at least cannot reuse 
> > the same UTXO to probe other potential acceptors.
> > (though, my understanding, there is no clear way to determine when we can 
> > safely delete old PoDLEs: maybe each node can keep it around for a month, 
> > which might be good enough to limit the practical ability of a snoop to 
> > probe other nodes)
> > I believe JoinMarket also has solved the issue of allowing a UTXO to be 
> > used at most N times (for example due to "honest" failures, such as 
> > connectivity interruptions which might cause an abort of the protocol); I 
> > think it involves appending a single byte to something that is hashed, and 
> > ensuring its value is less than N, so that it can only be used from 0 to N 
> > - 1 (and thus allow a UTXO to be used at most N times).
> > Getting into contact with waxwing / Adam Gibson for this might be useful to 
> > fill out how PoDLE works and so on; basically, I believe this issue is a 
> > practically solved problem already for JoinMarket, though waxwing may be 
> > able to provide a more nuanced opinion.
> 

> I communicated with waxwing, and he said:
> 

> -   See also: https://joinmarket.me/blog/blog/poodle \[sic\].
> -   The counter I mentioned is implemented using the second generator point.
> -   The PoDLE construction requires the standard base point `G`, and 
> another generator point `J`.
> -   To create the generator point `J`, JoinMarket appends the counter 
> byte (the one used to limit N number of uses of the same UTXO) to `G`, hashes 
> it, then uses a coerce-to-point.
> -   PoDLE is sometimes called DLEQ elsewhere.
> -   There is no concrete answer on "when to delete old PoDLE"; JoinMarket 
> never deletes (though they might if throughput increases).
> -   Watermarks like `nLockTime`, `nSequence`, `nVersion` are currently fixed 
> values; JoinMarket sees no reason to change this since equal-valued CoinJoins 
> are otherwise obvious to chain analysis anyway.
> -   But note: JoinMarket implements PayJoin, which is not otherwise 
> obvious onchain, and does indeed do anti-fee-sniping emulation for PayJoin.
> -   JoinMarket also strives to make similar feerates across users.
> 

> In any case, for myself, my thoughts are:
> 

> -   I observe that our use-case is quite similar to a PayJoin:
> -   The opener proposes to make a payment (to a channel between the 
> opener and the acceptor, rather than outright giving control to the acceptor 
> as in PayJoin).
> -   The acceptor adds some UTXOs which will contribute to the payment 
> output (i.e. the channel).
> -   This probably does mean we want to later consider `nLockTime` 
> anti-fee-sniping as well in multi-funded channel opens.
> -   Speaking of multi-funded channel opens, it seems to me this interactive 
> tx construction mechanism as well can be later used for channel factories.
> -   Similarly, PoDLE techniques would be useful as well to multi-funded 
> channel factories.
> -   It would probably be a good idea to share PoDLE format with JoinMarket so 
> we can share PoDLE with them (there could be bridges that share PoDLE between 
> a JoinMarket maker and a Lightning node, and each network already has its own 
> gossip protocols, so LN just needs a gossip protocol for sharing PoDLEs as 
> well).
> -   Probably we can mandate in some BOLT spec to retain PoDLE for at least a 
> year or a month or two weeks or so, which 

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

[Antoine Riard]

> 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 mempool but that's fine if it does from the initiator
one.

Or are you talking about the commitment tx (different issue and there is
broader privacy leaks there) ?

> Darosior ( i'll stick with my pseudo, first names definitely don't have
enough entropy :-) )

Ahaha yeah this pseudo-random-name-generator is definitely not trustworthy
:p


Le jeu. 30 janv. 2020 à 13:19, darosior  a écrit :

> 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 
> On Jan 30, 2020, 19:09, Antoine Riard < antoine.ri...@gmail.com> wrote:
>
>
> 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 IMO that's
> fine if at least the initiator is able to do so. We are requiring peers
> to be weakly in sync before operating channel anyway (`funding_locked`
> exchange).
>
> Funding_tx can already be drop from mempool for others
> reasons like mempool shrinks or expiry so broadcaster
> should always be ready to re-send it or bump feerate.
>
> Or are you describing another issue ?
>
> Le jeu. 30 janv. 2020 à 04:06, darosior  a
> écrit :
>
>> 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 of reorg the funding tx (now non-final) would be dropped
>> from mempool ? But you could set nLockTime to, say, tip - 6. (niftynei)
>>
>>
>> Antoine
>>
>>
>>  Original Message 
>> On Jan 30, 2020, 01:21, Antoine Riard < antoine.ri...@gmail.com> wrote:
>>
>>
>> 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 the current proposal hold, if you are a bit
>> more
>> tolerant and bridge peer don't send a tx_complete before receiving ones
>> from all its peers.
>>
>> What about transactions format ? I think we should coordinate with
>> Coinjoin
>> people to converge to a common one to avoid leaking protocol usage when
>> we can hinder under Taproot. Like setting the nLocktime or sorting inputs
>> in some protocol-specific fashion. Ideally we should have a BIP for format
>> but every layer 2 protocols its own set of messages concerning the
>> construction.
>>
>> > nLocktime is always set to 0x00
>> Maybe we can implement anti-fee sniping and mask among wallet core
>> txn set:
>> https://github.com/bitcoin/bitcoin/blob/aabec94541e23a67a9f30dc2c80dab3383a01737/src/wallet/wallet.cpp#L2519
>> ?
>>
>> > In the case of a close, a failed collaborative close would result in an
>> error and a uninlateral close"
>> Or can we do first a mutual closing tx, hold tx broadcast for a bit if
>> "opt_dual_fund"
>> is signaled to see if a tx_construction + add_funding_input for the
>> channel is received
>> soon ? At least that would be a dual opt-in to know than one party can
>> submit a funding-outpoint
>> as part of a composed tx ?
>>
>> Antoine
>>
>> Le lun. 27 janv. 2020 à 20:51, lisa neigut  a écrit :
>>
>>> 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 constructing a transaction to two participants.
>>> We're also going to likely want to reuse this portion of the protocol
>>> for batched closings and splicing. To that extent, it seemed useful to
>>> highlight it in a separate email.
>>>
>>> This is a change from the existing proposal in the dual-funding PR #524
>>>  -- it
>>> allows for the removal of inputs and outputs.
>>>
>>> The set of messages are as follows.
>>>
>>>
>>> Note that the 'initiation' of this protocol will be different depending
>>> on the case of the transaction (open, close or splice):
>>>
>>> 1. 

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

[Antoine Riard]

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 IMO that's
fine if at least the initiator is able to do so. We are requiring peers
to be weakly in sync before operating channel anyway (`funding_locked`
exchange).

Funding_tx can already be drop from mempool for others
reasons like mempool shrinks or expiry so broadcaster
should always be ready to re-send it or bump feerate.

Or are you describing another issue ?

Le jeu. 30 janv. 2020 à 04:06, darosior  a écrit :

> 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 of reorg the funding tx (now non-final) would be dropped
> from mempool ? But you could set nLockTime to, say, tip - 6. (niftynei)
>
>
> Antoine
>
>
>  Original Message 
> On Jan 30, 2020, 01:21, Antoine Riard < antoine.ri...@gmail.com> wrote:
>
>
> 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 the current proposal hold, if you are a bit
> more
> tolerant and bridge peer don't send a tx_complete before receiving ones
> from all its peers.
>
> What about transactions format ? I think we should coordinate with Coinjoin
> people to converge to a common one to avoid leaking protocol usage when
> we can hinder under Taproot. Like setting the nLocktime or sorting inputs
> in some protocol-specific fashion. Ideally we should have a BIP for format
> but every layer 2 protocols its own set of messages concerning the
> construction.
>
> > nLocktime is always set to 0x00
> Maybe we can implement anti-fee sniping and mask among wallet core
> txn set:
> https://github.com/bitcoin/bitcoin/blob/aabec94541e23a67a9f30dc2c80dab3383a01737/src/wallet/wallet.cpp#L2519
> ?
>
> > In the case of a close, a failed collaborative close would result in an
> error and a uninlateral close"
> Or can we do first a mutual closing tx, hold tx broadcast for a bit if
> "opt_dual_fund"
> is signaled to see if a tx_construction + add_funding_input for the
> channel is received
> soon ? At least that would be a dual opt-in to know than one party can
> submit a funding-outpoint
> as part of a composed tx ?
>
> Antoine
>
> Le lun. 27 janv. 2020 à 20:51, lisa neigut  a écrit :
>
>> 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 constructing a transaction to two participants.
>> We're also going to likely want to reuse this portion of the protocol
>> for batched closings and splicing. To that extent, it seemed useful to
>> highlight it in a separate email.
>>
>> This is a change from the existing proposal in the dual-funding PR #524
>>  -- it
>> allows for the removal of inputs and outputs.
>>
>> The set of messages are as follows.
>>
>>
>> Note that the 'initiation' of this protocol will be different depending
>> on the case of the transaction (open, close or splice):
>>
>> 1. type:   440 `tx_add_input`
>>
>> 2. data:
>>
>> * [`32*byte`:`channel_identifier`]
>>
>> * [`u64`:`sats`]
>>
>> * [`sha256`:`prevtx_txid`]
>>
>> * [`u32`:`prevtx_vout`]
>>
>> * [`u16`:`prevtx_scriptpubkey_len`]
>>
>> * [`prevtx_scriptpubkey_len*byte`:`prevtx_scriptpubkey`]
>>
>> * [`u16`:`max_witness_len`]
>>
>> * [`u16`:`scriptlen`]
>>
>> * [`scriptlen*byte`:`script`]
>>
>> * [`byte`:`signal_rbf`]
>>
>> 1. type: 442 `tx_add_output`
>>
>> 2. data:
>>
>> * [`32*byte`:`channel_identifier`]
>>
>> * [`u64`:`sats`]
>>
>> * [`u16`:`scriptlen`]
>>
>> * [`scriptlen*byte`:`script`]
>>
>> 1. type: 444 `tx_remove_input`
>>
>> 2. data:
>>
>> * [`32*byte`:`channel_identifier`]
>>
>> * [`sha256`:`prevtx_txid`]
>>
>> * [`u32`:`prevtx_vout`]
>>
>> 1. type: 446 `tx_remove_output`
>>
>> 2. data:
>>
>> * [`32*byte`:`channel_identifier`]
>>
>> * [`u64`:`sats`]
>>
>> * [`u16`:`scriptlen`]
>>
>> * [`scriptlen*byte`:`script`]
>>
>> 1. type: 448 `tx_complete`
>>
>> 2. data:
>>
>> * [`32*byte`:`channel_identifier`]
>>
>> * [`u16`:`num_inputs`]
>>
>> * [`u16`:`num_outputs`]
>>
>> 1. type:  448 `tx_sigs`
>>

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

[ZmnSCPxj via Lightning-dev]

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 something at stake in order to be revealed some 
> of the accepter's utxos.
> Thus, the opener giving the accepter a signed transaction commited to the 
> channel opening is one way of avoiding the opener to probe gratuitously. I 
> was thinking of something like:
>
> A is opener, B is accepter.
> A could sign the first input (and accordingly the 2of2 output) with 
> SIGHASH_SINGLE|SIGHASH_ANYONECANPAY. Unfortunately this doesn't handle A's 
> change, but it can be solved using a chain of transaction.
> A creates a first transaction txA1:
>
> txA1 (SIGHASH_ALL)
>  _ __
> | A's input 1| A's channel participation |
> ||---
> | A's input 2| A's change|
> ||---
> | A's input n|
> ||
>
>
> And then creates /signs the funding transaction out of the first output of 
> txA1:
>
> txA2 (SIGHASH_SINGLE|SIGHASH_ANYONECANPAY)
>  _ ___
> | txA1 vout 0| 2of2 with B|
> ||
>
> Since txA2 is signed with SINGLE|ANYONECANPAY, B can add inputs to fulfill 
> the value requirement of the 2of2, and add outputs for its own change.
>
> This comes at the cost of more setup fees opener-side, but avoids the 
> accepter to be gratuitously probed, so this is arguably a far lesser evil.
> Is there any other downside I'm missing here ?

This is an excellent idea.
A drawback is that anything that is not `SIGHASH_ALL` sticks out in chain 
analysis.
This is not an issue currently with Lightning since every 2-of-2 is (almost) 
definitely a Lightning Channel, but future improvements (Schnorr, Taproot) let 
us get better hiding, so the `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` is a 
massive flag.
As the point of protecting against this kind of probing is privacy, this is not 
a perfect privacy solution.


We could also consider PoDLE as used in JoinMarket, which solves a similar 
problem.
https://gist.github.com/AdamISZ/9cbba5e9408d23813ca8#defence-2-committing-to-a-utxo-in-publicplaintext-at-the-start-of-the-handshake
Basically, a PoDLE commits to a UTXO, without being trivially grindable from 
the UTXO set and also including a proof that the creator of the PoDLE knows the 
secret key behind it.
It can later be opened to reveal which UTXO the opener allocated.
If the opener aborts (i.e. does not provide its signatures to the funding 
transaction) then the acceptor can gossip the UTXO and the revealed PoDLE as 
well to the rest of Lightning, so that the opener at least cannot reuse the 
same UTXO to probe other potential acceptors.
(though, my understanding, there is no clear way to determine *when* we can 
safely delete old PoDLEs: maybe each node can keep it around for a month, which 
might be good enough to limit the practical ability of a snoop to probe other 
nodes)
I believe JoinMarket also has solved the issue of allowing a UTXO to be used at 
most N times (for example due to "honest" failures, such as connectivity 
interruptions which might cause an abort of the protocol); I think it involves 
appending a single byte to something that is hashed, and ensuring its value is 
less than N, so that it can only be used from 0 to N - 1 (and thus allow a UTXO 
to be used at most N times).

Getting into contact with waxwing / Adam Gibson for this might be useful to 
fill out how PoDLE works and so on; basically, I believe this issue is a 
practically solved problem already for JoinMarket, though waxwing may be able 
to provide a more nuanced opinion.

Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[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 revealed some 
of the accepter's utxos.
Thus, the opener giving the accepter a signed transaction commited to the 
channel opening is one way of avoiding the opener to probe gratuitously. I was 
thinking of something like:

A is opener, B is accepter.
A could sign the first input (and accordingly the 2of2 output) with 
SIGHASH_SINGLE|SIGHASH_ANYONECANPAY. Unfortunately this doesn't handle A's 
change, but it can be solved using a chain of transaction.
A creates a first transaction txA1:

txA1 (SIGHASH_ALL)
 _ __
| A's input 1| A's channel participation |
||---
| A's input 2| A's change|
||---
| A's input n|
||



And then creates /signs the funding transaction out of the first output of txA1:

txA2 (SIGHASH_SINGLE|SIGHASH_ANYONECANPAY)
 _ ___
| txA1 vout 0| 2of2 with B|
||

Since txA2 is signed with SINGLE|ANYONECANPAY, B can add inputs to fulfill the 
value requirement of the 2of2, and add outputs for its own change.

This comes at the cost of more setup fees opener-side, but avoids the accepter 
to be gratuitously probed, so this is arguably a far lesser evil.
Is there any other downside I'm missing here ?

Antoine

‐‐‐ Original Message ‐‐‐
Le mardi, janvier 28, 2020 2:51 AM, lisa neigut  a écrit :

> 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 constructing a transaction to two participants. We're also 
> going to likely want to reuse this portion of the protocol for batched 
> closings and splicing. To that extent, it seemed useful to highlight it in a 
> separate email.
> 

> This is a change from the existing proposal in the dual-funding PR #524 -- it 
> allows for the removal of inputs and outputs.
> 

> The set of messages are as follows.
> 

> Note that the 'initiation' of this protocol will be different depending on 
> the case of the transaction (open, close or splice):
> 

> 1. type:   440 `tx_add_input`
> 

> 2. data:
> 

> * [`32*byte`:`channel_identifier`]
> 

> * [`u64`:`sats`]
> 

> * [`sha256`:`prevtx_txid`]
> 

> * [`u32`:`prevtx_vout`]
> 

> * [`u16`:`prevtx_scriptpubkey_len`]
> 

> * [`prevtx_scriptpubkey_len*byte`:`prevtx_scriptpubkey`]
> 

> * [`u16`:`max_witness_len`]
> 

> * [`u16`:`scriptlen`]
> 

> * [`scriptlen*byte`:`script`]
> 

> * [`byte`:`signal_rbf`]
> 

> 1. type: 442 `tx_add_output`
> 

> 2. data:
> 

> * [`32*byte`:`channel_identifier`]
> 

> * [`u64`:`sats`]
> 

> * [`u16`:`scriptlen`]
> 

> * [`scriptlen*byte`:`script`]
> 

> 1. type: 444 `tx_remove_input`
> 

> 2. data:
> 

> * [`32*byte`:`channel_identifier`]
> 

> * [`sha256`:`prevtx_txid`]
> 

> * [`u32`:`prevtx_vout`]
> 

> 1. type: 446 `tx_remove_output`
> 

> 2. data:
> 

> * [`32*byte`:`channel_identifier`]
> 

> * [`u64`:`sats`]
> 

> * [`u16`:`scriptlen`]
> 

> * [`scriptlen*byte`:`script`]
> 

> 1. type: 448 `tx_complete`
> 

> 2. data:
> 

> * [`32*byte`:`channel_identifier`]
> 

> * [`u16`:`num_inputs`]
> 

> * [`u16`:`num_outputs`]
> 

> 1. type:  448 `tx_sigs`
> 

> 2. data:
> 

> * [`channel_id`:`channel_identifier`]
> 

> * [`u16`:`num_witnesses`]
> 

> * [`num_witnesses*witness_stack`:`witness_stack`]
> 

> 1. subtype: `witness_stack`
> 

> 2. data:
> 

> * [`sha256`:`prevtx_txid`]
> 

> * [`u32`:`prevtx_vout`]
> 

> * [`u16`:`num_input_witness`]
> 

> * [`num_input_witness*witness_element`:`witness_element`]
> 

> 1. subtype: `witness_element`
> 

> 2. data:
> 

> * [`u16`:`len`]
> 

> * [`len*byte`:`witness`]
> 

> ## General Notes
> 

> - Validity of inputs/outputs is not checked until both peers have sent 
> consecutive `tx_complete`  messages.
> 

> - Duplicate inputs or outputs is a protocol error.
> 

> - Feerate is set by the initiator, or in the case of a closing transaction, 
> negotiated before the transaction construction is initiated.
> 

> - Every peer pays fees for the inputs + outputs they contribute, plus enough 
> to cover the maximum estimate of their witnesses. Overpayment of fees is 
> permissible.
> 

> - Initiator is responsible for contributing the output/input in question, 
> i.e. the 
> 

>   funding output in 

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

[Max Dignan]

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 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 
>> solution to this?
>> 
>> -Max
>> ___
>> Lightning-dev mailing list
>> Lightning-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[Antoine Riard]

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 disabling nSequence and core wallet transactions
doing anti-fee snipping. Now even if all of them are using Taproot outputs
you're still leaking what protocol/tooling you're using to an external
observer
due to discrepancies in transaction fields. So we should obfuscate or using
standard values as much as protocol semantics let us doing it to break chain
analysis heuristics.

Le mer. 29 janv. 2020 à 21:00, lisa neigut  a écrit :

> 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 solution to this?
>>
>> -Max
>> ___
>> Lightning-dev mailing list
>> Lightning-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[lisa neigut]

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
> solution to this?
>
> -Max
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[Max Dignan]

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
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[Antoine Riard]

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 the current proposal hold, if you are a bit more
tolerant and bridge peer don't send a tx_complete before receiving ones
from all its peers.

What about transactions format ? I think we should coordinate with Coinjoin
people to converge to a common one to avoid leaking protocol usage when
we can hinder under Taproot. Like setting the nLocktime or sorting inputs
in some protocol-specific fashion. Ideally we should have a BIP for format
but every layer 2 protocols its own set of messages concerning the
construction.

> nLocktime is always set to 0x00
Maybe we can implement anti-fee sniping and mask among wallet core
txn set:
https://github.com/bitcoin/bitcoin/blob/aabec94541e23a67a9f30dc2c80dab3383a01737/src/wallet/wallet.cpp#L2519
?

> In the case of a close, a failed collaborative close would result in an
error and a uninlateral close"
Or can we do first a mutual closing tx, hold tx broadcast for a bit if
"opt_dual_fund"
is signaled to see if a tx_construction + add_funding_input for the channel
is received
soon ? At least that would be a dual opt-in to know than one party can
submit a funding-outpoint
as part of a composed tx ?

Antoine

Le lun. 27 janv. 2020 à 20:51, lisa neigut  a écrit :

> 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 constructing a transaction to two participants.
> We're also going to likely want to reuse this portion of the protocol for
> batched closings and splicing. To that extent, it seemed useful to
> highlight it in a separate email.
>
> This is a change from the existing proposal in the dual-funding PR #524
>  -- it allows
> for the removal of inputs and outputs.
>
> The set of messages are as follows.
>
>
> Note that the 'initiation' of this protocol will be different depending
> on the case of the transaction (open, close or splice):
>
> 1. type:   440 `tx_add_input`
>
> 2. data:
>
> * [`32*byte`:`channel_identifier`]
>
> * [`u64`:`sats`]
>
> * [`sha256`:`prevtx_txid`]
>
> * [`u32`:`prevtx_vout`]
>
> * [`u16`:`prevtx_scriptpubkey_len`]
>
> * [`prevtx_scriptpubkey_len*byte`:`prevtx_scriptpubkey`]
>
> * [`u16`:`max_witness_len`]
>
> * [`u16`:`scriptlen`]
>
> * [`scriptlen*byte`:`script`]
>
> * [`byte`:`signal_rbf`]
>
> 1. type: 442 `tx_add_output`
>
> 2. data:
>
> * [`32*byte`:`channel_identifier`]
>
> * [`u64`:`sats`]
>
> * [`u16`:`scriptlen`]
>
> * [`scriptlen*byte`:`script`]
>
> 1. type: 444 `tx_remove_input`
>
> 2. data:
>
> * [`32*byte`:`channel_identifier`]
>
> * [`sha256`:`prevtx_txid`]
>
> * [`u32`:`prevtx_vout`]
>
> 1. type: 446 `tx_remove_output`
>
> 2. data:
>
> * [`32*byte`:`channel_identifier`]
>
> * [`u64`:`sats`]
>
> * [`u16`:`scriptlen`]
>
> * [`scriptlen*byte`:`script`]
>
> 1. type: 448 `tx_complete`
>
> 2. data:
>
> * [`32*byte`:`channel_identifier`]
>
> * [`u16`:`num_inputs`]
>
> * [`u16`:`num_outputs`]
>
> 1. type:  448 `tx_sigs`
>
> 2. data:
>
> * [`channel_id`:`channel_identifier`]
>
> * [`u16`:`num_witnesses`]
>
> * [`num_witnesses*witness_stack`:`witness_stack`]
>
> 1. subtype: `witness_stack`
>
> 2. data:
>
> * [`sha256`:`prevtx_txid`]
>
> * [`u32`:`prevtx_vout`]
>
> * [`u16`:`num_input_witness`]
>
> * [`num_input_witness*witness_element`:`witness_element`]
>
> 1. subtype: `witness_element`
>
> 2. data:
>
> * [`u16`:`len`]
>
> * [`len*byte`:`witness`]
>
>
>
> ## General Notes
>
> - Validity of inputs/outputs is not checked until both peers have sent
> consecutive `tx_complete`  messages.
>
> - Duplicate inputs or outputs is a protocol error.
>
> - Feerate is set by the initiator, or in the case of a closing
> transaction, negotiated before the transaction construction is initiated.
>
> - Every peer pays fees for the inputs + outputs they contribute, plus
> enough to cover the maximum estimate of their witnesses. Overpayment of
> fees is permissible.
>
> - Initiator is responsible for contributing the output/input in question,
> i.e. the
>
>   funding output in the case of an opening, or the funding input in the
> case of a close.
>
>   (This means that the opener will pay for the opening output). In the
> case of a splice,
>
>   the initiator of the splice pays for the funding tx's inclusion as an
> input and the
>
>   new 'funding tx' output.
>
> - Any contributor may signal that their input is RBF'able. The 

[Lightning-dev] DRAFT: interactive tx construction protocol

[lisa neigut]

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 constructing a transaction to two participants.
We're also going to likely want to reuse this portion of the protocol for
batched closings and splicing. To that extent, it seemed useful to
highlight it in a separate email.

This is a change from the existing proposal in the dual-funding PR #524
 -- it allows
for the removal of inputs and outputs.

The set of messages are as follows.


Note that the 'initiation' of this protocol will be different depending on
the case of the transaction (open, close or splice):

1. type:   440 `tx_add_input`

2. data:

* [`32*byte`:`channel_identifier`]

* [`u64`:`sats`]

* [`sha256`:`prevtx_txid`]

* [`u32`:`prevtx_vout`]

* [`u16`:`prevtx_scriptpubkey_len`]

* [`prevtx_scriptpubkey_len*byte`:`prevtx_scriptpubkey`]

* [`u16`:`max_witness_len`]

* [`u16`:`scriptlen`]

* [`scriptlen*byte`:`script`]

* [`byte`:`signal_rbf`]

1. type: 442 `tx_add_output`

2. data:

* [`32*byte`:`channel_identifier`]

* [`u64`:`sats`]

* [`u16`:`scriptlen`]

* [`scriptlen*byte`:`script`]

1. type: 444 `tx_remove_input`

2. data:

* [`32*byte`:`channel_identifier`]

* [`sha256`:`prevtx_txid`]

* [`u32`:`prevtx_vout`]

1. type: 446 `tx_remove_output`

2. data:

* [`32*byte`:`channel_identifier`]

* [`u64`:`sats`]

* [`u16`:`scriptlen`]

* [`scriptlen*byte`:`script`]

1. type: 448 `tx_complete`

2. data:

* [`32*byte`:`channel_identifier`]

* [`u16`:`num_inputs`]

* [`u16`:`num_outputs`]

1. type:  448 `tx_sigs`

2. data:

* [`channel_id`:`channel_identifier`]

* [`u16`:`num_witnesses`]

* [`num_witnesses*witness_stack`:`witness_stack`]

1. subtype: `witness_stack`

2. data:

* [`sha256`:`prevtx_txid`]

* [`u32`:`prevtx_vout`]

* [`u16`:`num_input_witness`]

* [`num_input_witness*witness_element`:`witness_element`]

1. subtype: `witness_element`

2. data:

* [`u16`:`len`]

* [`len*byte`:`witness`]



## General Notes

- Validity of inputs/outputs is not checked until both peers have sent
consecutive `tx_complete`  messages.

- Duplicate inputs or outputs is a protocol error.

- Feerate is set by the initiator, or in the case of a closing transaction,
negotiated before the transaction construction is initiated.

- Every peer pays fees for the inputs + outputs they contribute, plus
enough to cover the maximum estimate of their witnesses. Overpayment of
fees is permissible.

- Initiator is responsible for contributing the output/input in question,
i.e. the

  funding output in the case of an opening, or the funding input in the
case of a close.

  (This means that the opener will pay for the opening output). In the case
of a splice,

  the initiator of the splice pays for the funding tx's inclusion as an
input and the

  new 'funding tx' output.

- Any contributor may signal that their input is RBF'able. The nSequence
for this input should be set to 0xFEFF , 0x otherwise.

- The initiating peer is understood to be paying the fee for the shared
transaction fields (nVersion [4], segwit marker + flag [2], input + output
counts [2-18], witness count [1-9], nLocktime [4]; total [13-40bytes])

- Inputs MUST be segwit compatible (PW* or P2SH-PW*)

- All output scripts must be standard

- nLocktime is always set to 0x.

- The `num_inputs` and `num_outputs` in `tx_complete` is a count of that
peer’s final input and output contributions, net any removals.

- Either peer may add or remove inputs and outputs until both peers have
successfully

  exchanged a `tx_complete` message in succession.

- Either peer may only add or remove their own input or output.

- In the case that a `tx_complete` agreement cannot be reached, either peer
may

  fail the channel or open protocol (whatever is reasonable for the
particular case)

  - In the case of a splice, this would be a soft error (channel returns to
normal operation until

otherwise failed or closed.)

  - In the case of an open, this would be a failure to open the channel.

  - In the case of a close, a failed collaborative close would result in an
error and a unilateral close.

### Considering the Simple Open case (2 parties)

- Both peers signal `opt_dual_fund`

- Opener initiates a channel open with `open_channel2` message, indicating
the feerate for the opening transaction

- Accepter signals acceptance of channel open as proposed, including
proposed feerate, via `accept_channel2`

- Opener sends `tx_add_output`, with the funding output for the sum of both
peer’s funding_amount

- Opener sends `tx_add_input` for each input the wish to add to the funding