{"type":"rich","version":"1.0","title":"lisa neigut [ARCHIVE] wrote","author_name":"lisa neigut [ARCHIVE] (npub1sp…s64t2)","author_url":"https://yabu.me/npub1sprhp66c693av0c0n9had046hcdcckp2th25fnmphwstc5e4wg9qxs64t2","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2020-02-10\n📝 Original message:\n\u003e But if you impose the blockheight - 6 in the Lightning protocol level,\nand Lightning succeeds (meaning a substantial fraction of blockchain\ntransactions are Lightning opens)...\n\u003e  --- then transactions with `nLockTime` equal to the block they are\nincluded in minus 5 will be more common than others, and would be a\nreliable indicator that the transaction is a Lightning channel funding\nattempt.\n\nAh good point. This can be mitigated by setting the acceptable range up to\n100 then, matching the behavior of bitcoind.\n\u003chttps://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L2507-L2544\u003e\n\n\n\n\n\nOn Thu, Feb 6, 2020 at 6:23 PM ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\n\u003e Good morning lisa,\n\u003e\n\u003e \u003e \u003e I am unsure what is the purpose of this minus 6.\n\u003e \u003e\n\u003e \u003e The original motivation was to keep the funding transaction from being\n\u003e rejected from the mempool in the case of a re-org, but as you pointed out,\n\u003e the 'next block' is always at -par or ahead of the current chain tip, so\n\u003e I'm not sure this accomplishes this goal.  I'm not sure how bitcoind\n\u003e handles the mempool in the case of the 'best block' moving to another tip,\n\u003e the goal of setting it to -6 is to avoid the funding transaction being\n\u003e evicted.\n\u003e\n\u003e My understanding is that it rewinds the abandoned tip, putting the\n\u003e transactions in those blocks back into its local mempool (which may lead to\n\u003e evictions if the mempool gets full), all the way to the branch-off point,\n\u003e then it re-adds blocks back to the new tip (which can lead to removals from\n\u003e the mempool, if transactions in the block spend the same UTXOs (or *are*\n\u003e the same transactions) as transactions in the mempool).\n\u003e The main effect is that there could be suddenly higher fee pressure for\n\u003e the transactions in the reorged-away blocks (because of possible mempool\n\u003e congestion if the longer chainsplit has fewer transactions per block), but\n\u003e that is why the dual-funding protocol has RBF built-in right?\n\u003e\n\u003e Setting blockheight - 6 also increases the incentive of potential\n\u003e deliberate reorgers to actually perform a reorg attack, because the\n\u003e transaction you just added is valid for earlier blocks that the reorger\n\u003e wants to rewrite.\n\u003e This is a bad thing, because you want your funding txout to be confirmed,\n\u003e not have parts of global hashpower contemplating reorgs and delaying your\n\u003e confirmations even more.\n\u003e\n\u003e\n\u003e \u003e\n\u003e \u003e In practice, setting the locktime back a few blocks makes the funding\n\u003e transaction eligible for inclusion in any of the previous six blocks, so in\n\u003e case of a reorg there's a higher probability it will have been included in\n\u003e the reorganization. In other words, it enables fee-sniping for up to 6\n\u003e blocks in the hopes that any 'eligible' re-org includes the funding\n\u003e transaction (the short channel id will change, but otherwise the channel\n\u003e open will be the same).\n\u003e \u003e\n\u003e \u003e On second thought, this doesn't seem like something that we should\n\u003e include at the protocol level; if a peer wanted to 'allow fee-sniping for\n\u003e up to X blocks', then they'd simply relay the \"blocktip\" that they're using\n\u003e for the nLocktime to be at the depth they'd desire. Though it might be\n\u003e worth imposing a limit as to how far back in the past a peer can allow\n\u003e fee-sniping for... no more than 6 blocks from our current tip seems\n\u003e reasonable. (This would then limit the 'acceptable range' for an offset of\n\u003e an initiator to 5, as your peer may be off from your tip by one.)\n\u003e \u003e\n\u003e \u003e On that note, I believe bitcoind fuzzes the nLocktime value to obfuscate\n\u003e exactly what blockheight the outgoing transaction was composed / broadcast\n\u003e at, which is probably something we should encourage in lightning\n\u003e implementations as well.\n\u003e\n\u003e But if you impose the blockheight - 6 in the Lightning protocol level, and\n\u003e Lightning succeeds (meaning a substantial fraction of blockchain\n\u003e transactions are Lightning opens) --- then transactions with `nLockTime`\n\u003e equal to the block they are included in minus 5 will be more common than\n\u003e others, and would be a reliable indicator that the transaction is a\n\u003e Lightning channel funding attempt.\n\u003e The fuzzing may not be big enough to cover that, as there is a 10% chance\n\u003e to fuzz and about 1% subsequent chance (total 0.1% chance) that Bitcoin ore\n\u003e will put a transaction at blockheight - 6 (as opposed to the 99 other\n\u003e possibilities: blockheight - 0 to blockheight - 99 inclusive).\n\u003e So once more than 0.1% of onchain transactions are Lightning\n\u003e dual-fundings, an analyst has \u003e 50% chance of correctly betting that a\n\u003e blockheight - 5 transaction (yes, - 5, because a transaction can typically\n\u003e be added only on the next block) is a Lightning funding.\n\u003e\n\u003e\n\u003e You are better off with blockheight, possibly with SPV-header-chain-proofs\n\u003e if one side or the other thinks the blockheight has changed since one side\n\u003e or the other proposed it.\n\u003e\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n\u003e \u003e\n\u003e \u003e On Wed, Feb 5, 2020 at 8:25 PM ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\u003e \u003e\n\u003e \u003e \u003e Good morning niftynei,\n\u003e \u003e \u003e\n\u003e \u003e \u003e \u003e Rusty had some suggestions about how to improve the protocol\n\u003e messages for this, namely adding a serial_id to the inputs and outputs,\n\u003e which can then be reused for deletions.\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e The serial id can then also be used as the ordering heuristic for\n\u003e transaction inputs during construction (replacing current usage of BIP69).\n\u003e Inputs can be shared amongst peers by flipping the bottom bit of the\n\u003e serial_id before relaying them to another peer (as your own).\n\u003e \u003e \u003e\n\u003e \u003e \u003e What happens if the initiator deliberately provides serial IDs 0x1,\n\u003e 0x3, .... while the acceptor naively provides serial IDs from\n\u003e `/dev/urandom`?\n\u003e \u003e \u003e\n\u003e \u003e \u003e Then the balance of probability is that the initiator inputs and\n\u003e outputs are sorted before the acceptor.\n\u003e \u003e \u003e Now, this is probably not an issue, since the initiator and acceptor\n\u003e both know which inputs and outputs are theirs and not theirs, so they could\n\u003e just reveal this information to anyone, so an actor providing such lousy\n\u003e serial IDs is just hurting its own privacy relative to blockchain analysts,\n\u003e so probably will not happen in practice.\n\u003e \u003e \u003e\n\u003e \u003e \u003e My initial reaction was to propose adding a secret-sharing round where\n\u003e the resulting key is XORed to each serial ID before sorting by the XORed\n\u003e serial ID, but this might be too overweight, and again the initiator is\n\u003e only hurting its own privacy, and the two participants already know whose\n\u003e money is whose anyway....\n\u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e See below for details.\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e 1. type:   440 `tx_add_input`\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e 2. data:\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e     * [`32*byte`:`channel_identifier`]\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e         * [`32*byte`:``serial_id`]\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e Add a serial id.\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e Each input addition must have a unique serial id.\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e No addition may have a repeated id number.\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e The initiator's serial id's must be odd. The non-initiator's serial\n\u003e id's must be even.\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e Serial ids are used as sorting heuristic for input ordering in final\n\u003e transaction, replaces BIP69\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e     * [`u64`:`sats`]\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e     * [`sha256`:`prevtx_txid`]\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e     * [`u32`:`prevtx_vout`]\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e     * [`u16`:`prevtx_scriptpubkey_len`]\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e     * [`prevtx_scriptpubkey_len*byte`:`prevtx_scriptpubkey`]\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e     * [`u16`:`max_witness_len`]\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e     * [`u16`:`scriptlen`]\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e     * [`scriptlen*byte`:`script`]\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e Removes the signal_rbf; everything will be flagged as RBF eligible.\n\u003e (This makes verifying RBF eligibility during a RBF round simpler.)\n\u003e \u003e \u003e\n\u003e \u003e \u003e Yes. Ish.\n\u003e \u003e \u003e RBF and privacy do not work well together unfortunately.\n\u003e \u003e \u003e This is still initiator-pays, right?\n\u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e 1. subtype: `witness_element`\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e 2. data:\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e     * [`u16`:`len`]\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e     * [`len*byte`:`witness`]\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e ## General Notes\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e - All output scripts must be standard\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e - nLocktime is always set to 0x00000000\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e - If a blockheight to be used as nLocktime is communicated in the\n\u003e initiation step, is set to blockheight-6; otherwise set to zero-\n\u003e \u003e \u003e\n\u003e \u003e \u003e I am unsure what is the purpose of this minus 6.\n\u003e \u003e \u003e\n\u003e \u003e \u003e If you fear blockheight disagreements, this is probably a good time to\n\u003e introduce block headers.\n\u003e \u003e \u003e So for example if the acceptor thinks the initiator blockheight is too\n\u003e high, it could challenge the initiator to give block headers from its known\n\u003e blockheight to the initiator blockheight.\n\u003e \u003e \u003e If the acceptor thinks the initiator blockheight is too low, it could\n\u003e provide block headers itself as proof.\n\u003e \u003e \u003e This could be limited so that gross differences in blockheight are\n\u003e outright rejected by the acceptor (it could `error` the temporary channel\n\u003e ID rather than accept it).\n\u003e \u003e \u003e\n\u003e \u003e \u003e This is SPV, but neither side is actually making or accepting a\n\u003e payment *yet*, just synchronizing clocks, so maybe not as bad as normal SPV.\n\u003e \u003e \u003e\n\u003e \u003e \u003e Massive chain reorgs cannot reduce blockheight, only increase it (else\n\u003e the reorg attempt fails in the first place) so there must still exist at\n\u003e least one chain(split) with the highest known blockheight already given a\n\u003e proof-of-header-chain, and all you really need is some mining activity on\n\u003e top of *one* split that confirms your funding transaction.\n\u003e \u003e \u003e\n\u003e \u003e \u003e If it is not because of blockheight disagreements or massive chain\n\u003e reorgs, what is the purpose of `blockheight - 6`?\n\u003e \u003e \u003e\n\u003e \u003e \u003e \u003e - Serial ids should be chosen at random\n\u003e \u003e \u003e \u003e - For multiparty constructions, the initiator MUST flip the bottom\n\u003e bit of any received inputs before relaying them to a peer.\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e - Collisions of serial ids between peers is a protocol error\n\u003e \u003e \u003e\n\u003e \u003e \u003e I suppose we should define collision to mean \"equal in all bits except\n\u003e the lowest bit\".\n\u003e \u003e \u003e\n\u003e \u003e \u003e Regards,\n\u003e \u003e \u003e ZmnSCPxj\n\u003e\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200210/26f95449/attachment-0001.html\u003e"}