lisa neigut [ARCHIVE] on Nostr: 📅 Original date posted:2020-02-10 📝 Original message: > But if you impose the ...

📅 Original date posted:2020-02-10
📝 Original message:
> 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.
<https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L2507-L2544>;





On Thu, Feb 6, 2020 at 6:23 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> 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 <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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200210/26f95449/attachment-0001.html>;