[Lightning-dev] DRAFT: interactive tx construction protocol

[ZmnSCPxj]

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 <ZmnSCPxj at protonmail.com> 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 0x00000000
> > >
> > > - 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