rich1.0lisa neigut [ARCHIVE] wrotelisa neigut [ARCHIVE] (npub1sp…s64t2)https://yabu.me/npub1sprhp66c693av0c0n9had046hcdcckp2th25fnmphwstc5e4wg9qxs64t2njumphttps://yabu.me📅 Original date posted:2020-02-04
📝 Original message:
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).
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.)
> 1. type: 442 `tx_add_output`
>
> 2. data:
>
> * [`32*byte`:`channel_identifier`]
>
* [`16*byte`:`serial_id`]
Add a serial id. Same rules as for inputs, but a distinct counter set is
used.
Used for ordering the transactions’ outputs, replacing BIP69
> * [`u64`:`sats`]
>
> * [`u16`:`scriptlen`]
>
> * [`scriptlen*byte`:`script`]
>
> 1. type: 444 `tx_remove_input`
>
> 2. data:
>
> * [`32*byte`:`channel_identifier`]
>
* [`16*byte`:`serial_id`]
Input to remove identified by the serial id, not txid and index.
>
> 1. type: 446 `tx_remove_output`
>
> 2. data:
>
> * [`32*byte`:`channel_identifier`]
>
* [`16*byte`:`serial_id]
Output to remove identified by the serial id, not output script and amount.
> 1. type: 448 `tx_complete`
>
> 2. data:
>
> * [`32*byte`:`channel_identifier`]
>
Total counts removed from tx_complete. The txid exchanged in the `tx_sigs`
will serves as a checksum for the transaction.
> 1. type: 448 `tx_sigs`
>
> 2. data:
>
> * [`channel_id`:`channel_identifier`]
>
> * [`u16`:`num_witnesses`]
>
> * [`num_witnesses*witness_stack`:`witness_stack`]
>
> 1. subtype: `witness_stack`
>
> 2. data:
>
* [`u16`:`num_input_witness`]
>
> * [`num_input_witness*witness_element`:`witness_element`]
>
prev_out and prev_txid are removed; witnesses ordered implicitly by
serial_id.
> 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-
- 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200204/d6136e56/attachment-0001.html>