{"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-04\n📝 Original message:\nRusty had some suggestions about how to improve the protocol messages for\nthis, namely adding a serial_id to the inputs and outputs, which can then\nbe reused for deletions.\n\nThe serial id can then also be used as the ordering heuristic for\ntransaction inputs during construction (replacing current usage of BIP69).\nInputs can be shared amongst peers by flipping the bottom bit of the\nserial_id before relaying them to another peer (as your own).\n\nSee below for details.\n\n\n1. type:   440 `tx_add_input`\n\u003e\n\u003e 2. data:\n\u003e\n\u003e     * [`32*byte`:`channel_identifier`]\n\u003e\n        * [`32*byte`:``serial_id`]\n\nAdd a serial id.\n\nEach input addition must have a unique serial id.\n\nNo addition may have a repeated id number.\n\nThe initiator's serial id's must be odd. The non-initiator's serial id's\nmust be even.\nSerial ids are used as sorting heuristic for input ordering in final\ntransaction, replaces BIP69\n\n\n    * [`u64`:`sats`]\n\u003e\n\u003e     * [`sha256`:`prevtx_txid`]\n\u003e\n\u003e     * [`u32`:`prevtx_vout`]\n\u003e\n\u003e     * [`u16`:`prevtx_scriptpubkey_len`]\n\u003e\n\u003e     * [`prevtx_scriptpubkey_len*byte`:`prevtx_scriptpubkey`]\n\u003e\n\u003e     * [`u16`:`max_witness_len`]\n\u003e\n\u003e     * [`u16`:`scriptlen`]\n\u003e\n\u003e     * [`scriptlen*byte`:`script`]\n\u003e\n\u003e Removes the signal_rbf; everything will be flagged as RBF eligible. (This\nmakes verifying RBF eligibility during a RBF round simpler.)\n\n\n\u003e 1. type: 442 `tx_add_output`\n\u003e\n\u003e 2. data:\n\u003e\n\u003e     * [`32*byte`:`channel_identifier`]\n\u003e\n    * [`16*byte`:`serial_id`]\n\nAdd a serial id. Same rules as for inputs, but a distinct counter set is\nused.\nUsed for ordering the transactions’ outputs, replacing BIP69\n\n\n\n\u003e     * [`u64`:`sats`]\n\u003e\n\u003e     * [`u16`:`scriptlen`]\n\u003e\n\u003e     * [`scriptlen*byte`:`script`]\n\u003e\n\u003e 1. type: 444 `tx_remove_input`\n\u003e\n\u003e 2. data:\n\u003e\n\u003e     * [`32*byte`:`channel_identifier`]\n\u003e\n    * [`16*byte`:`serial_id`]\n\n\nInput to remove identified by the serial id, not txid and index.\n\n\n\n\u003e\n\u003e 1. type: 446 `tx_remove_output`\n\u003e\n\u003e 2. data:\n\u003e\n\u003e     * [`32*byte`:`channel_identifier`]\n\u003e\n    * [`16*byte`:`serial_id]\n\nOutput to remove identified by the serial id, not output script and amount.\n\n\n\n\u003e 1. type: 448 `tx_complete`\n\u003e\n\u003e 2. data:\n\u003e\n\u003e     * [`32*byte`:`channel_identifier`]\n\u003e\n\nTotal counts removed from tx_complete. The txid exchanged in the `tx_sigs`\nwill serves as a checksum for the transaction.\n\n\n\u003e 1. type:  448 `tx_sigs`\n\u003e\n\u003e 2. data:\n\u003e\n\u003e     * [`channel_id`:`channel_identifier`]\n\u003e\n\u003e     * [`u16`:`num_witnesses`]\n\u003e\n\u003e     * [`num_witnesses*witness_stack`:`witness_stack`]\n\u003e\n\u003e 1. subtype: `witness_stack`\n\u003e\n\u003e 2. data:\n\u003e\n    * [`u16`:`num_input_witness`]\n\u003e\n\u003e     * [`num_input_witness*witness_element`:`witness_element`]\n\u003e\n\nprev_out and prev_txid are removed; witnesses ordered implicitly by\nserial_id.\n\n\n\u003e 1. subtype: `witness_element`\n\u003e\n\u003e 2. data:\n\u003e\n\u003e     * [`u16`:`len`]\n\u003e\n\u003e     * [`len*byte`:`witness`]\n\u003e\n\u003e\n\u003e\n\u003e ## General Notes\n\u003e\n\u003e - All output scripts must be standard\n\u003e\n\u003e - nLocktime is always set to 0x00000000\n\u003e\n- If a blockheight to be used as nLocktime is communicated in the\ninitiation step, is set to blockheight-6; otherwise set to zero-\n- Serial ids should be chosen at random\n- For multiparty constructions, the initiator MUST flip the bottom bit of\nany received inputs before relaying them to a peer.\n- Collisions of serial ids between peers is a protocol error\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200204/d6136e56/attachment-0001.html\u003e"}