{"type":"rich","version":"1.0","title":"darosior [ARCHIVE] wrote","author_name":"darosior [ARCHIVE] (npub1pj…x22xp)","author_url":"https://yabu.me/npub1pj9022f74rzq7d5x7gnxje6wpsgk4r5jgeck8y5awd423ydhan3q7x22xp","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2020-01-30\n📝 Original message:\n\u003e Yes that's the reason I wrote the initiator can just announce its own and receiver use it to sign the funding tx, even if receiver tip is backward. Funding tx won't propagate from receiver mempool but that's fine if it does from the initiator one.\n\n\n\n\n\n\n\nAh, then we are back to my first response where niftynei proposed to accord on setting it to tip-6 so that reorg is not a problem (or if it is, there are bigger).\n\\-------- Original Message --------\nOn Jan 30, 2020, 19:45, Antoine Riard \u003c antoine.riard at gmail.com\u003e wrote:\n\n\u003e\n\u003e\n\u003e\n\u003e \u003e The funding transaction sig would actually fail verification if tip differs between funder and fundee\n\u003e\n\u003e\n\u003e\n\u003e Yes that's the reason I wrote the initiator can just\n\u003e\n\u003e\n\u003e announce its own and receiver use it to sign the funding tx,\n\u003e\n\u003e\n\u003e even if receiver tip is backward. Funding tx won't propagate\n\u003e\n\u003e\n\u003e from receiver mempool but that's fine if it does from the initiator\n\u003e\n\u003e one.\n\u003e\n\u003e\n\u003e\n\u003e Or are you talking about the commitment tx (different issue and there is\n\u003e\n\u003e\n\u003e broader privacy leaks there) ?\n\u003e\n\u003e \u003e Darosior ( i'll stick with my pseudo, first names definitely don't have enough entropy :-) )\n\u003e\n\u003e\n\u003e\n\u003e Ahaha yeah this pseudo-random-name-generator is definitely not trustworthy :p\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e Le jeu. 30 janv. 2020 à 13:19, darosior \u003c[darosior at protonmail.com][darosior_protonmail.com]\u003e a écrit :\n\u003e\n\u003e\n\u003e \u003e Sorry I wasn't clear enough in the \\`(cdecker)\\` paragraph.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e The funding transaction sig would actually fail verification if tip differs between funder and fundee.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e Darosior ( i'll stick with my pseudo, first names definitely don't have enough entropy :-) )\n\u003e \u003e \\-------- Original Message --------\n\u003e \u003e On Jan 30, 2020, 19:09, Antoine Riard \u003c [antoine.riard at gmail.com][antoine.riard_gmail.com]\u003e wrote:\n\u003e \u003e\n\u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e \u003e \u003e Hey Darosior,\n\u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e \u003e \u003e You don't need a strict synchronization between both peers,\n\u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e \u003e \u003e just let nLocktime picked up by initiator and announce it at\n\u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e \u003e \u003e same time than feerate or at \\`tx\\_complete\\`. Worst-case,\n\u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e \u003e \u003e a slow-block-processing receiver may not be able to get\n\u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e \u003e \u003e the transaction accepted by its local mempool, but IMO that's\n\u003e \u003e \u003e fine if at least the initiator is able to do so. We are requiring peers\n\u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e \u003e \u003e to be weakly in sync before operating channel anyway (\\`funding\\_locked\\`\n\u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e \u003e \u003e exchange).\n\u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e \u003e \u003e Funding\\_tx can already be drop from mempool for others\n\u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e \u003e \u003e reasons like mempool shrinks or expiry so broadcaster\n\u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e \u003e \u003e should always be ready to re-send it or bump feerate.\n\u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e \u003e \u003e Or are you describing another issue ?\n\u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e \u003e \u003e Le jeu. 30 janv. 2020 à 04:06, darosior \u003c[darosior at protonmail.com][darosior_protonmail.com]\u003e a écrit :\n\u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e \u003e \u003e \u003e Hi Antoine and all,\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e About nLockTime fun thing is Lisa, Cdecker and I had this conversation to integrate it to C-lightning just yesterday.\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e Unfortunately you need to add a \"My tip is xxxx\" to the openchannel msg, otherwise if you set nLockTime to tip. (cdecker)\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e Moreover in case of reorg the funding tx (now non-final) would be dropped from mempool ? But you could set nLockTime to, say, tip - 6. (niftynei)\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e Antoine\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \\-------- Original Message --------\n\u003e \u003e \u003e \u003e On Jan 30, 2020, 01:21, Antoine Riard \u003c [antoine.riard at gmail.com][antoine.riard_gmail.com]\u003e wrote:\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e Hey thanks for this proposal!\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e 2 high-level questions:\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e What about multi-party tx construction ? By multi-party, let's define\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e Alice initiate a tx construction to Bob and then Bob announce a\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e construction to Caroll and \"bridge\" all inputs/outputs additions/substractions\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e in both directions. I think the current proposal hold, if you are a bit more\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e tolerant and bridge peer don't send a tx\\_complete before receiving ones\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e from all its peers.\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e What about transactions format ? I think we should coordinate with Coinjoin\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e people to converge to a common one to avoid leaking protocol usage when\n\u003e \u003e \u003e \u003e \u003e we can hinder under Taproot. Like setting the nLocktime or sorting inputs\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e in some protocol-specific fashion. Ideally we should have a BIP for format\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e but every layer 2 protocols its own set of messages concerning the construction.\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e nLocktime is always set to 0x000000\n\u003e \u003e \u003e \u003e \u003e Maybe we can implement anti-fee sniping and mask among wallet core\n\u003e \u003e \u003e \u003e \u003e txn set: [https://github.com/bitcoin/bitcoin/blob/aabec94541e23a67a9f30dc2c80dab3383a01737/src/wallet/wallet.cpp\\#L2519][https_github.com_bitcoin_bitcoin_blob_aabec94541e23a67a9f30dc2c80dab3383a01737_src_wallet_wallet.cpp_L2519] ?\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e In the case of a close, a failed collaborative close would result in an error and a uninlateral close\"\n\u003e \u003e \u003e \u003e \u003e Or can we do first a mutual closing tx, hold tx broadcast for a bit if \"opt\\_dual\\_fund\"\n\u003e \u003e \u003e \u003e \u003e is signaled to see if a tx\\_construction + add\\_funding\\_input for the channel is received\n\u003e \u003e \u003e \u003e \u003e soon ? At least that would be a dual opt-in to know than one party can submit a funding-outpoint\n\u003e \u003e \u003e \u003e \u003e as part of a composed tx ?\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e Antoine\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e Le lun. 27 janv. 2020 à 20:51, lisa neigut \u003c[niftynei at gmail.com][niftynei_gmail.com]\u003e a écrit :\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e Some of the feedback I received from the check-in for the dual-funding proposal this past Monday was along the lines that we look at simplifying for breaking it into smaller, more manageable chunks.\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e The biggest piece of the dual-funding protocol update is definitely the move from a single peer constructing a transaction to two participants. We're also going to likely want to reuse this portion of the protocol for batched closings and splicing. To that extent, it seemed useful to highlight it in a separate email.\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e This is a change from the existing proposal in the dual-funding [PR \\#524][PR _524] \\-- it allows for the removal of inputs and outputs.\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e The set of messages are as follows.\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e Note that the 'initiation' of this protocol will be different depending on the case of the transaction (open, close or splice):\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e 1. type:   440 \\`tx\\_add\\_input\\`\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e 2. data:\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \\* \\[\\`32\\*byte\\`:\\`channel\\_identifier\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \\* \\[\\`u64\\`:\\`sats\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \\* \\[\\`sha256\\`:\\`prevtx\\_txid\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \\* \\[\\`u32\\`:\\`prevtx\\_vout\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \\* \\[\\`u16\\`:\\`prevtx\\_scriptpubkey\\_len\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \\* \\[\\`prevtx\\_scriptpubkey\\_len\\*byte\\`:\\`prevtx\\_scriptpubkey\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \\* \\[\\`u16\\`:\\`max\\_witness\\_len\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \\* \\[\\`u16\\`:\\`scriptlen\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \\* \\[\\`scriptlen\\*byte\\`:\\`script\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \\* \\[\\`byte\\`:\\`signal\\_rbf\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e 1. type: 442 \\`tx\\_add\\_output\\`\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e 2. data:\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \\* \\[\\`32\\*byte\\`:\\`channel\\_identifier\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \\* \\[\\`u64\\`:\\`sats\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \\* \\[\\`u16\\`:\\`scriptlen\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \\* \\[\\`scriptlen\\*byte\\`:\\`script\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e 1. type: 444 \\`tx\\_remove\\_input\\`\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e 2. data:\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \\* \\[\\`32\\*byte\\`:\\`channel\\_identifier\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \\* \\[\\`sha256\\`:\\`prevtx\\_txid\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \\* \\[\\`u32\\`:\\`prevtx\\_vout\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e 1. type: 446 \\`tx\\_remove\\_output\\`\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e 2. data:\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \\* \\[\\`32\\*byte\\`:\\`channel\\_identifier\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \\* \\[\\`u64\\`:\\`sats\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \\* \\[\\`u16\\`:\\`scriptlen\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \\* \\[\\`scriptlen\\*byte\\`:\\`script\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e 1. type: 448 \\`tx\\_complete\\`\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e 2. data:\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \\* \\[\\`32\\*byte\\`:\\`channel\\_identifier\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \\* \\[\\`u16\\`:\\`num\\_inputs\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \\* \\[\\`u16\\`:\\`num\\_outputs\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e 1. type:  448 \\`tx\\_sigs\\`\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e 2. data:\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \\* \\[\\`channel\\_id\\`:\\`channel\\_identifier\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \\* \\[\\`u16\\`:\\`num\\_witnesses\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \\* \\[\\`num\\_witnesses\\*witness\\_stack\\`:\\`witness\\_stack\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e 1. subtype: \\`witness\\_stack\\`\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e 2. data:\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \\* \\[\\`sha256\\`:\\`prevtx\\_txid\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \\* \\[\\`u32\\`:\\`prevtx\\_vout\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \\* \\[\\`u16\\`:\\`num\\_input\\_witness\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \\* \\[\\`num\\_input\\_witness\\*witness\\_element\\`:\\`witness\\_element\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e 1. subtype: \\`witness\\_element\\`\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e 2. data:\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \\* \\[\\`u16\\`:\\`len\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     \\* \\[\\`len\\*byte\\`:\\`witness\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\#\\# General Notes\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- Validity of inputs/outputs is not checked until both peers have sent consecutive \\`tx\\_complete\\`  messages.\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- Duplicate inputs or outputs is a protocol error.\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- Feerate is set by the initiator, or in the case of a closing transaction, negotiated before the transaction construction is initiated.\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- Every peer pays fees for the inputs + outputs they contribute, plus enough to cover the maximum estimate of their witnesses. Overpayment of fees is permissible.\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- Initiator is responsible for contributing the output/input in question, i.e. the \n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e   funding output in the case of an opening, or the funding input in the case of a close. \n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e   (This means that the opener will pay for the opening output). In the case of a splice,\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e   the initiator of the splice pays for the funding tx's inclusion as an input and the\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e   new 'funding tx' output.\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- Any contributor may signal that their input is RBF'able. The nSequence for this input should be set to 0xFEFF FFFF, 0xFFFFFFFF otherwise.\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- The initiating peer is understood to be paying the fee for the shared transaction fields (nVersion \\[4\\], segwit marker + flag \\[2\\], input + output counts \\[2-18\\], witness count \\[1-9\\], nLocktime \\[4\\]; total \\[13-40bytes\\])\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- Inputs MUST be segwit compatible (PW\\* or P2SH-PW\\*)\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- All output scripts must be standard\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- nLocktime is always set to 0x00000000.\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- The \\`num\\_inputs\\` and \\`num\\_outputs\\` in \\`tx\\_complete\\` is a count of that peer’s final input and output contributions, net any removals.\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- Either peer may add or remove inputs and outputs until both peers have successfully\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e   exchanged a \\`tx\\_complete\\` message in succession.\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- Either peer may only add or remove their own input or output.\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- In the case that a \\`tx\\_complete\\` agreement cannot be reached, either peer may\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e   fail the channel or open protocol (whatever is reasonable for the particular case)\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e   - In the case of a splice, this would be a soft error (channel returns to normal operation until      \n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     otherwise failed or closed.)\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e   - In the case of an open, this would be a failure to open the channel.\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e   - In the case of a close, a failed collaborative close would result in an error and a unilateral close.\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\#\\#\\# Considering the Simple Open case (2 parties)\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- Both peers signal \\`opt\\_dual\\_fund\\`\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- Opener initiates a channel open with \\`open\\_channel2\\` message, indicating the feerate for the opening transaction\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- Accepter signals acceptance of channel open as proposed, including proposed feerate, via \\`accept\\_channel2\\`\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- Opener sends \\`tx\\_add\\_output\\`, with the funding output for the sum of both peer’s funding\\_amount\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- Opener sends \\`tx\\_add\\_input\\` for each input the wish to add to the funding transaction\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- Opener sends \\`tx\\_add\\_output\\` for their change \n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- Opener sends \\`tx\\_complete\\`\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- Accepter sends \\`tx\\_add\\_input\\` for each input they wish to add to the funding transaction\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- Accepter sends \\`tx\\_add\\_output\\` for their change.\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- Accepter sends \\`tx\\_complete\\`\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- Opener sends \\`tx\\_complete\\`\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- Opener and accepter exchange commitment signatures; etc.\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\#\\#\\# Considering the Splice case:\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- Both peers signal \\`opt\\_splice\\_ok\\`\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- One peer initiates a splice, also signaling the feerate for the transaction. Exact protocol unspecified herein.\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- Initiator sends \\`tx\\_add\\_input\\` with the original funding output\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- Initiator sends \\`tx\\_add\\_output\\` with the new, post-splice funding output\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- Initiator sends \\`tx\\_add\\_input/output\\` as needed to add all desired inputs + outputs\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- Initiator sends \\`tx\\_complete\\`\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- Peer sends \\`tx\\_add\\_input/output\\` as needed to add all desired inputs + outputs\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- Initiator sends \\`tx\\_complete\\`\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- Peer sends \\`tx\\_complete\\`\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- Initiator + peer exchange commitment signatures, etc.\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\#\\#\\# Considering the Close case:\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- Both peers signal \\`opt\\_collaborative\\_close\\` in their \\`node\\_announcement\\`.\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- A peer initiates a close sending a \\`shutdown\\`, as per usual. \n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- A feerate is negotiated. Out of band for this particular portion of the protocol.\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\-The closing initiator (peer which first sent \\`shutdown\\`), sends \\`tx\\_add\\_input\\` to spend the funding output and \\`tx\\_add\\_output\\` to add their output for the channel closure.\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- The peer responds with \\`tx\\_add\\_output\\`, adding their output to the close transaction.\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- If \\`option\\_upfront\\_shutdown\\_script\\` is flagged but no such output with a value at or within a reasonable feerate gap of the peer's funding output is present, then the peer must fail the channel. \n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\#\\# Updating a collaborative transaction with RBF:\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- If any input is flagged as RBF’able, then the transaction is considered eligible for RBF\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- RBF can be initiated by either party, and serves as an initiation for another round of transaction composition, as outlined above.\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\- Note that this section has been cribbed and re-purposed from the original RBF proposal for splicing, see https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001621.html\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e 1. type: 45 (\\`init\\_rbf\\`) (\\`option\\_collaborative\\_rbf\\`)\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e 2. data:\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e    \\* \\[\\`32\\`:\\`channel\\_id\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e    \\* \\[\\`4\\`:\\`fee\\_step\\`\\]\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e Each \\`fee\\_step\\` adds 1/4 (rounded down) to the initial \n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e transaction feerate. eg. if the initial feerate was 512 satoshis per kiloweight, \\`fee\\_step\\` 1\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e is  512 + 512 / 4 = 640, \\`fee\\_step\\` 2 is 640 + 640 / 4 = 800.\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e The sender:\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e   - MUST set \\`fee\\_step\\` greater than zero and greater than any prior \\`fee\\_step\\`.\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e The recipient:\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e   - if the new fee exceeds the sender's current balance minus reserve\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     after it is applied to the splice transaction:\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e     - MUST error.\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e   \n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e NOTES:\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e 1. 1/4 is a reasonable minimal RBF, but as each one requires more\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e    tracking by the recipient, serves to limit the number you can create.\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e 2. Rule 4 of BIP125 requires a feerate increase to at least surpass the minimum transaction relay setting. Ratcheting by 25% should satisfy this requirement\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e 3. An additional rule will be added to the checks of an RBF transaction that it must include at least one identical, replaceable input as the original transaction.\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e \u003e \\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\n\u003e \u003e \u003e \u003e \u003e \u003e Lightning-dev mailing list\n\u003e \u003e \u003e \u003e \u003e \u003e [Lightning-dev at lists.linuxfoundation.org][Lightning-dev_lists.linuxfoundation.org]\n\u003e \u003e \u003e \u003e \u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e \u003e \u003e \u003e \u003e \u003e\n\n\n[darosior_protonmail.com]: mailto:darosior at protonmail.com\n[antoine.riard_gmail.com]: mailto:antoine.riard at gmail.com\n[https_github.com_bitcoin_bitcoin_blob_aabec94541e23a67a9f30dc2c80dab3383a01737_src_wallet_wallet.cpp_L2519]: https://github.com/bitcoin/bitcoin/blob/aabec94541e23a67a9f30dc2c80dab3383a01737/src/wallet/wallet.cpp#L2519\n[niftynei_gmail.com]: mailto:niftynei at gmail.com\n[PR _524]: https://github.com/lightningnetwork/lightning-rfc/pull/524\n[Lightning-dev_lists.linuxfoundation.org]: mailto:Lightning-dev at lists.linuxfoundation.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200130/3aac971c/attachment-0001.html\u003e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 489 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200130/3aac971c/attachment-0001.sig\u003e"}