{"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-06\n📝 Original message:\n\u003e I am unsure what is the purpose of this minus 6.\n\nThe original motivation was to keep the funding transaction from being\nrejected from the mempool in the case of a re-org, but as you pointed out,\nthe 'next block' is always at -par or ahead of the current chain tip, so\nI'm not sure this accomplishes this goal.  I'm not sure how bitcoind\nhandles the mempool in the case of the 'best block' moving to another tip,\nthe goal of setting it to -6 is to avoid the funding transaction being\nevicted.\n\nIn practice, setting the locktime back a few blocks makes the funding\ntransaction eligible for inclusion in any of the previous six blocks, so in\ncase of a reorg there's a higher probability it will have been included in\nthe reorganization. In other words, it enables fee-sniping for up to 6\nblocks in the hopes that any 'eligible' re-org includes the funding\ntransaction (the short channel id will change, but otherwise the channel\nopen will be the same).\n\nOn second thought, this doesn't seem like something that we should include\nat the protocol level; if a peer wanted to 'allow fee-sniping for up to X\nblocks', then they'd simply relay the \"blocktip\" that they're using for the\nnLocktime to be at the depth they'd desire. Though it might be worth\nimposing a limit as to how far back in the past a peer can allow\nfee-sniping for... no more than 6 blocks from our current tip seems\nreasonable. (This would then limit the 'acceptable range' for an offset of\nan initiator to 5, as your peer may be off from your tip by one.)\n\nOn that note, I believe bitcoind fuzzes the nLocktime value to obfuscate\nexactly what blockheight the outgoing transaction was composed / broadcast\nat, which is probably something we should encourage in lightning\nimplementations as well.\n\n\n\nOn Wed, Feb 5, 2020 at 8:25 PM ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\n\u003e Good morning niftynei,\n\u003e\n\u003e\n\u003e \u003e Rusty had some suggestions about how to improve the protocol messages\n\u003e for this, namely adding a serial_id to the inputs and outputs, which can\n\u003e then be reused for deletions.\n\u003e \u003e\n\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\n\u003e What happens if the initiator deliberately provides serial IDs 0x1, 0x3,\n\u003e .... while the acceptor naively provides serial IDs from `/dev/urandom`?\n\u003e\n\u003e Then the balance of probability is that the initiator inputs and outputs\n\u003e are sorted before the acceptor.\n\u003e Now, this is probably not an issue, since the initiator and acceptor both\n\u003e know which inputs and outputs are theirs and not theirs, so they could just\n\u003e reveal this information to anyone, so an actor providing such lousy serial\n\u003e IDs is just hurting its own privacy relative to blockchain analysts, so\n\u003e probably will not happen in practice.\n\u003e\n\u003e My initial reaction was to propose adding a secret-sharing round where the\n\u003e resulting key is XORed to each serial ID before sorting by the XORed serial\n\u003e ID, but this might be too overweight, and again the initiator is only\n\u003e hurting its own privacy, and the two participants already know whose money\n\u003e is whose anyway....\n\u003e\n\u003e \u003e\n\u003e \u003e See below for details.\n\u003e \u003e\n\u003e \u003e \u003e 1. type:   440 `tx_add_input`\n\u003e \u003e \u003e\n\u003e \u003e \u003e 2. data:\n\u003e \u003e \u003e\n\u003e \u003e \u003e     * [`32*byte`:`channel_identifier`]\n\u003e \u003e\n\u003e \u003e         * [`32*byte`:``serial_id`]\n\u003e \u003e\n\u003e \u003e Add a serial id.\n\u003e \u003e\n\u003e \u003e Each input addition must have a unique serial id.\n\u003e \u003e\n\u003e \u003e No addition may have a repeated id number.\n\u003e \u003e\n\u003e \u003e The initiator's serial id's must be odd. The non-initiator's serial id's\n\u003e must be even.\n\u003e \u003e\n\u003e \u003e Serial ids are used as sorting heuristic for input ordering in final\n\u003e transaction, replaces BIP69\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e \u003e     * [`u64`:`sats`]\n\u003e \u003e \u003e\n\u003e \u003e \u003e     * [`sha256`:`prevtx_txid`]\n\u003e \u003e \u003e\n\u003e \u003e \u003e     * [`u32`:`prevtx_vout`]\n\u003e \u003e \u003e\n\u003e \u003e \u003e     * [`u16`:`prevtx_scriptpubkey_len`]\n\u003e \u003e \u003e\n\u003e \u003e \u003e     * [`prevtx_scriptpubkey_len*byte`:`prevtx_scriptpubkey`]\n\u003e \u003e \u003e\n\u003e \u003e \u003e     * [`u16`:`max_witness_len`]\n\u003e \u003e \u003e\n\u003e \u003e \u003e     * [`u16`:`scriptlen`]\n\u003e \u003e \u003e\n\u003e \u003e \u003e     * [`scriptlen*byte`:`script`]\n\u003e \u003e\n\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\n\u003e Yes. Ish.\n\u003e RBF and privacy do not work well together unfortunately.\n\u003e This is still initiator-pays, right?\n\u003e\n\u003e\n\u003e \u003e \u003e 1. subtype: `witness_element`\n\u003e \u003e \u003e\n\u003e \u003e \u003e 2. data:\n\u003e \u003e \u003e\n\u003e \u003e \u003e     * [`u16`:`len`]\n\u003e \u003e \u003e\n\u003e \u003e \u003e     * [`len*byte`:`witness`]\n\u003e \u003e \u003e\n\u003e \u003e \u003e ## General Notes\n\u003e \u003e \u003e\n\u003e \u003e \u003e - All output scripts must be standard\n\u003e \u003e \u003e\n\u003e \u003e \u003e - nLocktime is always set to 0x00000000\n\u003e \u003e\n\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\n\u003e I am unsure what is the purpose of this minus 6.\n\u003e\n\u003e If you fear blockheight disagreements, this is probably a good time to\n\u003e introduce block headers.\n\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 If the acceptor thinks the initiator blockheight is too low, it could\n\u003e provide block headers itself as proof.\n\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\n\u003e This is SPV, but neither side is actually making or accepting a payment\n\u003e *yet*, just synchronizing clocks, so maybe not as bad as normal SPV.\n\u003e\n\u003e Massive chain reorgs cannot reduce blockheight, only increase it (else the\n\u003e reorg attempt fails in the first place) so there must still exist at least\n\u003e 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\n\u003e If it is not because of blockheight disagreements or massive chain reorgs,\n\u003e what is the purpose of `blockheight - 6`?\n\u003e\n\u003e\n\u003e\n\u003e \u003e - Serial ids should be chosen at random\n\u003e \u003e - For multiparty constructions, the initiator MUST flip the bottom bit\n\u003e of any received inputs before relaying them to a peer.\n\u003e \u003e\n\u003e \u003e - Collisions of serial ids between peers is a protocol error\n\u003e\n\u003e I suppose we should define collision to mean \"equal in all bits except the\n\u003e lowest bit\".\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200206/f7cc9d4e/attachment-0001.html\u003e"}