rich1.0lisa neigut [ARCHIVE] (npub1sp…s64t2)https://yabu.me/npub1sprhp66c693av0c0n9had046hcdcckp2th25fnmphwstc5e4wg9qxs64t2njumphttps://yabu.me📅 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>