--- Log opened Wed Jan 26 00:00:41 2022 00:04 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has quit [Ping timeout: 268 seconds] 00:48 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has joined #bitcoin-core-pr-reviews 00:53 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has quit [Ping timeout: 250 seconds] 01:18 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net] 01:21 -!- luke-jr [~luke-jr@user/luke-jr] has joined #bitcoin-core-pr-reviews 01:22 -!- brunoerg [~brunoerg@187.183.47.88] has joined #bitcoin-core-pr-reviews 01:26 -!- brunoerg [~brunoerg@187.183.47.88] has quit [Ping timeout: 240 seconds] 01:56 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has joined #bitcoin-core-pr-reviews 02:00 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has quit [Ping timeout: 240 seconds] 02:30 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has joined #bitcoin-core-pr-reviews 02:34 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has quit [Ping timeout: 268 seconds] 02:52 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has joined #bitcoin-core-pr-reviews 02:54 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 03:07 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has joined #bitcoin-core-pr-reviews 03:50 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has quit [Remote host closed the connection] 03:51 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has joined #bitcoin-core-pr-reviews 04:26 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has quit [Remote host closed the connection] 04:36 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Quit: Leaving] 04:37 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews 04:44 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has joined #bitcoin-core-pr-reviews 04:48 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has quit [Ping timeout: 240 seconds] 05:19 -!- brunoerg [~brunoerg@187.183.47.88] has joined #bitcoin-core-pr-reviews 05:30 -!- provoostenator_ [~quassel@user/provoostenator] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.] 05:33 -!- provoostenator [~quassel@user/provoostenator] has joined #bitcoin-core-pr-reviews 05:56 -!- brunoerg [~brunoerg@187.183.47.88] has quit [Remote host closed the connection] 06:14 -!- brunoerg [~brunoerg@187.183.47.88] has joined #bitcoin-core-pr-reviews 06:19 -!- brunoerg [~brunoerg@187.183.47.88] has quit [Ping timeout: 268 seconds] 06:48 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has joined #bitcoin-core-pr-reviews 06:52 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has quit [Ping timeout: 240 seconds] 07:35 -!- jaonoctus [~jaonoctus@vmi550577.contaboserver.net] has joined #bitcoin-core-pr-reviews 07:38 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has joined #bitcoin-core-pr-reviews 07:39 -!- aferreira44 [~aferreira@177.220.174.62] has joined #bitcoin-core-pr-reviews 07:47 -!- aferreira44 [~aferreira@177.220.174.62] has quit [Quit: Connection closed] 07:50 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4dhoiqoswm06o.ipv6.telus.net] has joined #bitcoin-core-pr-reviews 07:56 -!- erik1 [~erik@181-191-0-203.uplinkx.com.br] has joined #bitcoin-core-pr-reviews 07:59 -!- erik1 [~erik@181-191-0-203.uplinkx.com.br] has quit [Client Quit] 08:03 -!- erik1 [~erik@181-191-0-203.uplinkx.com.br] has joined #bitcoin-core-pr-reviews 08:04 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has quit [Remote host closed the connection] 08:05 -!- brunoerg [~brunoerg@187.183.47.88] has joined #bitcoin-core-pr-reviews 08:22 -!- brunoerg [~brunoerg@187.183.47.88] has quit [Remote host closed the connection] 08:25 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has joined #bitcoin-core-pr-reviews 08:35 -!- observer51 [~observer@cpe-23-242-148-67.socal.res.rr.com] has joined #bitcoin-core-pr-reviews 08:36 -!- observer51 [~observer@cpe-23-242-148-67.socal.res.rr.com] has quit [Client Quit] 08:37 -!- jaonoctus24 [~jaonoctus@vmi550577.contaboserver.net] has joined #bitcoin-core-pr-reviews 08:39 -!- jaonoctus [~jaonoctus@vmi550577.contaboserver.net] has quit [Ping timeout: 250 seconds] 08:39 -!- jaonoctus24 [~jaonoctus@vmi550577.contaboserver.net] has quit [Client Quit] 08:39 -!- jaonoctus [~jaonoctus@vmi550577.contaboserver.net] has joined #bitcoin-core-pr-reviews 08:41 -!- erik1 is now known as erik-etsuji-kato 08:48 -!- btckid [~btckid@189.236.6.29] has joined #bitcoin-core-pr-reviews 08:51 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews 08:53 -!- oopsydanger [uid536846@id-536846.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews 08:55 -!- btckid [~btckid@189.236.6.29] has quit [Quit: Connection closed] 08:58 -!- btckid [~btckid@189.236.6.29] has joined #bitcoin-core-pr-reviews 08:58 -!- tarun [~tarun@cpe-174-97-2-41.cinci.res.rr.com] has joined #bitcoin-core-pr-reviews 08:59 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews 08:59 -!- narcelio [~narcelio@vmi550577.contaboserver.net] has joined #bitcoin-core-pr-reviews 08:59 -!- OliverOffing [~OliverOff@189.1.174.14] has joined #bitcoin-core-pr-reviews 08:59 -!- sanya [~sanya@178-223-17-164.dynamic.isp.telekom.rs] has joined #bitcoin-core-pr-reviews 09:00 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has joined #bitcoin-core-pr-reviews 09:01 < glozow> hi? 09:01 < stickies-v> hi 09:01 < svav> Hi 09:01 < narcelio> hi 09:01 < ziggie> Hi 09:01 < brunoerg> hi 09:01 < theStack_> hi 09:01 < btckid> hi 09:01 < jaonoctus> hi 09:01 < erik-etsuji-kato> hi 09:01 < larryruane> #startmeeting 09:01 < OliverOffing> hey everyone 09:01 < tarun> g=hi 09:01 < monlovesmango> hello 09:01 < lightlike> hi 09:01 < sipa> hi 09:01 < larryruane> Hi everyone! Welcome to another PR Review Club 09:02 -!- docallag [~docallag@2a02:8084:90e2:3a80:609d:4ae9:41c6:f17c] has joined #bitcoin-core-pr-reviews 09:02 < larryruane> Feel free to say hi to let everyone know you're here 09:02 < sanya> hi 09:02 < docallag> Hi. 09:02 < larryruane> anyone here for the first time? 09:02 < jaonoctus> gm 09:02 < monlovesmango> my first time :) 09:03 < larryruane> Today we're looking at #24007 "[mempool] allow tx replacement by smaller witness" 09:03 < larryruane> monlovesmango: welcome! 09:03 < monlovesmango> ty!! 09:03 < sdaftuar> hi 09:03 < larryruane> Here's the link to the notes and questions: https://bitcoincore.reviews/24007 09:04 < monlovesmango> I got it open thank you! 09:04 < larryruane> Who had a chance to review today's PR? y/n/partial and what was your approach? 09:04 < svav> n but read the notes 09:04 < ziggie> y 09:04 < brunoerg> 0.6y 09:04 < jaonoctus> y 09:04 < narcelio> y 09:04 < tarun> y 09:04 < erik-etsuji-kato> Code review only 09:04 < btckid> y/notes 09:05 < OliverOffing> n 09:05 < stickies-v> y, untested code¬es review 09:05 < docallag> y 09:05 < theStack_> 0.5y (only light conceptual review and code-reviewed the test so far) 09:06 < larryruane> mempool is a somewhat tricky area, would anyone like to summarize the PR? Feel free to add background if you'd like! 09:07 -!- aferreira44 [~aferreira@177.220.174.62] has joined #bitcoin-core-pr-reviews 09:07 < ziggie> This PR tries to introduce a new replacement option for transactions with different witnesses 09:07 < theStack_> the PR enables to replace txs in the mempool if only the witness data changes, but the remaining parts of the transactions are unchanged (i.e. same txid, different wtxid) 09:07 -!- JLPF [~JLPF@189.124.122.247] has joined #bitcoin-core-pr-reviews 09:08 < OliverOffing> this PR allows users to replace the witness data for a transaction in the mempool, as long as the new witness data is smaller (i.e. higher fee _rate_) 09:08 < stickies-v> If you want to change (and broadcast) the witness of an already broadcasted transaction (e.g. by spending a different path in the script), this is currently not allowed because the txid doesn't change when just the witness data changes. This PR allows such updated transactions to be acceptedin mempool and broadcasted, provided that the new witness is sufficiently small enough. 09:09 < larryruane> ziggie: theStack_: OliverOffing - correct, what's the current policy if a transaction arrives at the mempool but there's already a tx with the same txid? 09:09 < docallag> Rejected as an attempted double spend 09:09 < OliverOffing> discard it (first seen safe policy) 09:09 < theStack_> it is rejected 09:10 < larryruane> yes, good! maybe something basic now, what's the difference between a `txid` and a `wtxid`? Why are there two different IDs? 09:10 < svav> Current policy is that new transaction with same txid is immediately rejected 09:11 < OliverOffing> `txid` = hash(tx data), `wtxid` = hash(tx data + witness data) 09:11 < docallag> txid = hash of non-witness data, wtxid = hash of both 09:11 < stickies-v> txid is calculated as the hash of the serialized transaction without witness data (and thus malleable), wtxid is the hash of the serialized tx with witness data 09:11 < erik-etsuji-kato> TxId is the hash of legacy data only (all transaction data minus the witness stack an the flag), wTxId is the hash with the witness 09:11 < btckid> a txid hashes the non witness data while wtxid hashes both non witness data and witness data 09:12 < stickies-v> *not malleable instead of mallaeable 09:12 < jaonoctus> txid is a double sha256 of tx data (without the witness part) 09:12 < larryruane> all great answers ... What big change in (I think) 2017 introduced the concept of `wtxid`? 09:12 < brunoerg> segwit 09:12 < OliverOffing> segwit 09:12 < erik-etsuji-kato> segwit 09:12 < svav> Segregated witness 09:12 < btckid> segwit 09:13 < larryruane> hehe yes, too easy for you all! ... general cryptography term is "commited to" ... what does that mean? 09:13 < larryruane> (by the way, feel free to ask your own questions or lead the discussion elsewhere!) 09:13 < svav> Uniquely associated with? 09:13 < larryruane> *committed to 09:14 < ziggie> would it be possible to use the RBF signaling for replacing a tx with the same txid 09:14 < stickies-v> refer to a hash of 'something', so that when the 'something' in any way changes your reference becomes invalid 09:14 < larryruane> like, in this case, we say the wtxid "commits to" the witness, and you've all said the witness is included in computing wtxid, so why is it called that? 09:15 < larryruane> stickies-v: you got it, that's what I was looking for. If A commits to B, then you can't change B without changing A 09:16 < larryruane> (A usually (always?) being a hash) 09:16 < docallag> If the input and outputs have to be the same how would the witness data change? (please ignore if off topic) 09:17 < larryruane> No that's on-topic, good question. Anyone like to explain how that can happen? 09:17 < OliverOffing> a script can have multiple forks/paths, and different witness data can trigger different paths 09:17 < btckid> a change in the script path? 09:17 < docallag> Ah, tks! 09:18 < glozow> easiest example of a multi-spending path script is OP_DROP OP_TRUE 09:18 < glozow> and then the witness data can be literally anything 09:19 < glozow> er i guess, 1 item anything 09:19 < stickies-v> signatures are also malleable (hence segwit), so I think even without segwit that could be the case. It wouldn't hit the 5% witness size decrease requirement of this PR though, just for completeness 09:19 < larryruane> an tx output can be thought of as a lock, but the lock can possibly be unlockable with different "keys" ... each "key" corresponds to a different witness (very high level description) 09:19 < stickies-v> *even without P2SH, not "even without segwit". sorry 09:19 < docallag> Great examples. Thanks all. 09:20 < monlovesmango> ziggie: I don't think so bc RBF didn't change rule that duplicate txid is not allowed (bc RBF will always have new txid)...? 09:20 < glozow> docallag: see here for example code https://github.com/bitcoin/bitcoin/blob/e3699b71c46bf66cfe363fc76ab8761dc39555a7/src/test/txpackage_tests.cpp#L333 09:21 < larryruane> Okay, feel free to continue this line of thought, but if we're ready to move to the mempool ... the mempool is a collection of unconfirmed transactions, each represented by key-value pair (with unique keys, like a std::map) ... what is the key? 09:22 < brunoerg> txid? 09:22 < btckid> tcid 09:22 < btckid> txid 09:22 < OliverOffing> txid 09:22 < svav> txid 09:22 < narcelio> txid 09:22 < stickies-v> is there just a single key? if i understand correctly the mempool is indexed on 5 keys? 09:22 < lightlike> many keys, it's a multi index 09:22 < larryruane> yes, good, txid ... meaning, there can't be 2 transactions in the mempool with same txid ... but why? why don't we key on wtxid? 09:23 < larryruane> stickies-v: yes, exactly right, i'm at a very high level here :) 09:23 < glozow> we do key on wtxid though? 09:23 < OliverOffing> because indexing on wtxid would not prevent two txs from spending the same inputs 09:23 < larryruane> glozow: do we key on wtxid? 09:23 < stickies-v> https://github.com/bitcoin/bitcoin/blob/2935bd9d67e5a60171e570bde54a212a81d034e9/src/txmempool.h#L371-L376 09:23 < glozow> https://github.com/bitcoin/bitcoin/blob/e3699b71c46bf66cfe363fc76ab8761dc39555a7/src/txmempool.h#L184-L196 09:24 < glozow> https://github.com/bitcoin/bitcoin/blob/master/src/txmempool.h#L465 09:24 < larryruane> OliverOffing: perfect, that's exactly it! transactions in the mempool can _never_ be conflicting, and two transactions with the same txid are necessarily conflicting (spending the same inputs) 09:25 < glozow> mempool indexes by txid, wtxid, descendant feerate, ancestor feerate, and entry time 09:25 < larryruane> glozow: stickies-v: this lets us *look up* transactions by wtxid, but there can still not be two transactions with the same txid, right? I hope I have that right! 09:25 -!- observer5 [~observer@cpe-23-242-148-67.socal.res.rr.com] has joined #bitcoin-core-pr-reviews 09:26 < svav> Am I right in thinking txid will always be unique in the mempool whereas wtxid may not be? 09:26 < larryruane> svav: I don't think it's possible to have two (or more) tx with same wtxid but different txid 09:27 < stickies-v> larryruane it doesn't get accepted in mempool because it wouldn't pass MemPoolAccept::PreChecks but I don't think the CTxMempool wouldn't technically be able to? 09:27 < larryruane> unless you were extremely "lucky" (unlucky) 09:27 < lightlike> i think both must be unique because they are both boost::multi_index::hashed_unique indexes 09:27 < glozow> if the question is whether boost multi index container will let us have 2 entries, i'll need to go read the docs. if the question is whether our node will survive if we put 2 transactions with the same txid in the mempool, the answer is no 09:28 < larryruane> stickies-v: good point, I'm not sure if anything actually enforces no duplicate txids (other than conflicting spends), like, if you happened to have a collision 09:28 < svav> Can txid be regarded as a unique identifier as far as Bitcoin transactions are concerned? 09:29 < svav> Can anyone link to the code where txid and wtxid is generated? 09:30 < larryruane> svav: that's a great question, the answer is yes and no ... It's yes in the sense that two tx with the same txid must have the same *effect* (let's review, what is the effect of a tx? It's to destroy some UTXOs and create some new ones) ... but these two tx can be *enabled* by different witnesses, so they're different in that way ... Do I have this right? (I'm kind of new to this myself!) 09:31 < stickies-v> larryruane I was typing something very similar, agreed 09:32 < larryruane> we've covered more or less questions 1-3, let's quickly cover question 4, does this PR change a consensus rule? 09:32 < glozow> no 09:32 < erik-etsuji-kato> no 09:32 < brunoerg> no, mempool is individual 09:32 < jaonoctus> nope 09:33 < larryruane> correct, excellent ... what happens if some nodes are updated to run this PR and others aren't? does that cause a problem? 09:33 -!- narcelio [~narcelio@vmi550577.contaboserver.net] has quit [Quit: Connection closed] 09:34 < stickies-v> no, nodes that aren't updated will just not forward these transactions 09:34 < larryruane> (this is the type of thing we *always* have to worry about in bitcoin!) 09:35 < stickies-v> you do need sufficient nodes to be upgraded in order to somewhat reliably expect your transaction would be propagated to most miners 09:35 < larryruane> stickies-v: maybe, I think interestingly enough, if a node receives a tx with a txid that is already in its mempool, it re-broadcasts its *existing* tx - is that right glozow ? 09:35 * docallag Couldn't my (old) node broadcast the old transaction but your node (new) broadcast the new transaction? 09:35 -!- btckid [~btckid@189.236.6.29] has quit [Ping timeout: 240 seconds] 09:36 -!- Azor [~Azor@190.79.223.248] has joined #bitcoin-core-pr-reviews 09:36 < larryruane> stickies-v: yes (i was replying to your previous msg) 09:36 -!- observer5 [~observer@cpe-23-242-148-67.socal.res.rr.com] has quit [Quit: Connection closed] 09:36 < OliverOffing> different nodes would keep different transactions in the mempool but that's not really a problem for the network—only for the user trying to replace their tx's wit data as stickies-v mentioned 09:36 -!- jaonoctus87 [~jaonoctus@vmi550577.contaboserver.net] has joined #bitcoin-core-pr-reviews 09:36 < larryruane> docallag: yes, I think that's what does happen with this PR 09:36 < glozow> larryruane: oh no, I think that was fixed in #22261 https://github.com/bitcoin/bitcoin/pull/22261 09:36 -!- btckid [~btckid@189.236.6.29] has joined #bitcoin-core-pr-reviews 09:36 -!- jaonoctus87 [~jaonoctus@vmi550577.contaboserver.net] has quit [Client Quit] 09:37 < larryruane> glozow: +1 thanks 09:37 -!- jaonoctus50 [~jaonoctus@vmi550577.contaboserver.net] has joined #bitcoin-core-pr-reviews 09:38 < larryruane> Personally I think question 5 is really interesting ... Should Bitcoin Core mempool policy be miner-incentive compatible? If so, why? 09:38 < jaonoctus50> wdym by miner-incentive compatible? 09:39 < glozow> a mempool is as useful as it is an accurate reflection of what's in the miners mempools. being incentive-incompatible is a good way to deviate from what would be in a miner's mempool. so yes. 09:39 < stickies-v> I think so. If not, you encourage miners to set up individual backchannels (e.g. sending tx directly to miner for a direct fee) to help get non-standard transactions mined, and that puts smaller/anonymous miners at a disadvantage 09:39 < larryruane> jaonoctus50: should our mempool contain what (at least most) miners would *prefer* to have in their mempools? 09:39 < OliverOffing> yes, miners secure the network. the mempool needs be compatible with miner incentives so that the txs get to miners' nodes 09:39 -!- jaonoctus [~jaonoctus@vmi550577.contaboserver.net] has quit [Ping timeout: 268 seconds] 09:39 < svav> Are these definitions still correct? /////// Definition of txid remains unchanged: the double SHA256 of the traditional serialization format: 09:39 < svav>   [nVersion][txins][txouts][nLockTime] /////// A new wtxid is defined: the double SHA256 of the new serialization with witness data: 09:39 < svav>   [nVersion][marker][flag][txins][txouts][witness][nLockTime] 09:39 < theStack_> i think it should be, if i understand "miner-incentive compatible" correctly; we want miners to maximize their fees in order to increase the security 09:39 < lightlike> yes, because otherwise miners are incentivised to accept transactions by other ways than the p2p network, such as their own endpoints. 09:40 < larryruane> stickies-v: great answer, i hadn't thought of that! 09:40 < brunoerg> i think so, because we want to be aligned with them, just because we want to see our transactions being mined. 09:40 < larryruane> (and lightlike too, +1) 09:41 < larryruane> here's a crazy thought, BTW (not in the notes), we sometimes have these policies that we're not sure miners are following - maybe we can look at the tx that arrive in each *mined block* and dynamically adjust our policies to match! 09:42 < larryruane> to align better our mempool contents (and thus fee estimation, relay policies, etc.) with actual miner policies 09:42 < brunoerg> larryruane: make sense 09:42 < larryruane> probably too complicated, but just a thought 09:42 < stickies-v> larryruane but then you have to reverse engineer those policies from the results you observe? which seems far from trivial? 09:42 < erik-etsuji-kato> But this can be used by miners to, e.g, bump the fees artificilly 09:43 < erik-etsuji-kato> They can add fake high-fee transactions in ther mined blocks 09:43 < jaonoctus50> erik-etsuji-kato: good point 09:43 < larryruane> erik-etsuji-kato: great point ... it may be too weird to set up this circular dependency 09:43 < stickies-v> erik-etsuji-kato I'm not sure that's relevant here actually, because those transactions don't get propagated to the network (because then if someone else mines them, the miner loses money) 09:44 < larryruane> stickies-v: that's true, if mining is fairly decentralized 09:44 < OliverOffing> unless they collude 09:45 < OliverOffing> which is something plausible given that fees would increase across the board for everyone 09:45 -!- observer71 [~observer@cpe-23-242-148-67.socal.res.rr.com] has joined #bitcoin-core-pr-reviews 09:45 < monlovesmango> does witness data size impact the fees that miners collect? 09:45 < stickies-v> hmm they don't need to collude I think, any dishonest miner can do this, it's trivial to just construct some high fee tx's and inject them only into your own block. I just mean that this wouldn't affect policy, because they're not propagated out of block 09:46 < larryruane> okay let's see (but again, feel free to keep going on any previous thread), question 6, quick detour to RBF, when RBF occurs, why is it necessary to remove mempool decendants? Is that necessary for witness-replacement? 09:46 < stickies-v> monlovesmango yes it does, but it's discounted so each witness data byte is less expense than each non-witness data byte 09:46 < brunoerg> because the txid is changed 09:46 < stickies-v> 4 times less expensive, to be precise 09:46 < theStack_> after RBF occurs, the descendants of the replaced txs are not valid anymore, as they (directly or indirectly) spend invalid inputs 09:46 < erik-etsuji-kato> It changes the txid, invalidating the inputs in it's descendants 09:47 < brunoerg> in the case of witness-replacement, it doesnt happen because the txid doesnt change 09:47 < larryruane> monlovesmango: yes, because if a witness replacement occurs, the feerate improves, so that helps the miner 09:47 < theStack_> brunoerg: +1 09:47 < larryruane> brunoerg: can you elaborate, what does txid not changing mean? 09:48 < larryruane> oh i see theStack_ kind of answered this already, thanks 09:49 < larryruane> maybe we can cover 8 quickly, why does this PR allow witness-replacement even if the tx hasn't signaled replacability (which is required for RBF)? 09:49 < ziggie> would this change also affect the constuction of scripts to foresee some kind of competing scenario ? 09:49 < larryruane> (I think this has been answered already) 09:50 < OliverOffing> because neither inputs nor outputs change so no harm no faul? 09:50 < larryruane> (since txid isn't changing, downstream transactions' inputs aren't invalidated) 09:50 < theStack_> i think it has to do with the fact that the recipient doesn't are about a potential witness-replacement, as the outputs aren't changed? 09:50 < ziggie> so that you kind of padded script paths to make them equal size, just in case they will not meet this policy 09:50 < theStack_> *care 09:50 < erik-etsuji-kato> +larryruane: Any tx can be replaced by witness, without signaling 09:52 < ziggie> oh forget my question, I was missing the point that the witness only changes sry 09:52 < larryruane> theStack_: +1 ... RBF replacability signaling allows the downstream tx to worried.. but they're not worried in this case 09:52 < stickies-v> I think this would break protocols that rely on unconfirmed wtxids, but I don't think those protocols currently exist and that seems like an unreliable thing to do anyway so we probably shouldn't care? 09:53 -!- gleb7454386 [~gleb@178.150.137.228] has quit [Ping timeout: 240 seconds] 09:53 < theStack_> though, even without RBF signalling there is a reason to be worried, as the tx could just have a too-low fee and eventually get kicked out of the mempool, and _then_ get replaced? (probably a different discussion though) 09:54 < larryruane> I'd really love to get to question 9, I don't have good answers myself. There was a good comment on the PR just a few hours ago on these lines (what is the use case here?) - https://github.com/bitcoin/bitcoin/pull/24007#issuecomment-1022303102 09:54 < stickies-v> theStack_ yeah absolutely, and like with any 0conf protocols, one can always pay a miner to include a newer tx version anyway so... 09:56 < OliverOffing> larryruane that you ask it does seem a bit feature-creeping 09:57 < larryruane> OliverOffing: fair point ... So there's that question (9), and there are a few more questions (11-13) but only a few minutes left, anyone like to choose anything else to discuss? 09:57 < glozow> re: use cases, it seem like we would only be interested in this if there's a pinning attack. like, you have counterparties on your transaction and somebody bloats up the witness by thousands of vbytes or something. i can't imagine why a normal user is broadcasting their own transaction multiple times with various witnesses 09:57 -!- Azor [~Azor@190.79.223.248] has quit [Quit: Connection closed] 09:58 < jaonoctus50> glozow: +1 09:58 < stickies-v> larryruane I can potentially see this being useful in protocols where one party signals they're willing to go on chain in a suboptimal path by broadcasting that larger transaction, maybe encouraging all parties to instead lower the fees and go for key spend (in taproot case) instead 09:59 < stickies-v> a game of chicken, kind of 09:59 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews 09:59 < svav> Can anyone answer question 9)? 09:59 < larryruane> makes sense ... I guess overall, maybe the main argument is that allowing witness replacement is compatible with miner incentive, and it's not very complex 10:00 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 240 seconds] 10:00 < larryruane> svav: I think that will have to happen, and is happening, int the PR 10:00 < larryruane> ok we're at time, thanks everyone! 10:00 < theStack_> for question 12, i think the reason for multiplying both sides with an integer rather than one side with a float is to avoid floating-point arithmetics? 10:00 < theStack_> thanks for hosting larryruane! 10:00 < docallag> tks all, lots to digest 10:01 < larryruane> theStack_: +1 10:01 < jaonoctus50> ty 10:01 < docallag> glozow thanks for the links 10:01 < monlovesmango> larryruane: for the attack mentioned in that post, wouldn't it make more send to require the witness to be smaller by a certain byte size rather than percentage to eliminate this attack vector? or is there a reason we are using percentage of data size? 10:01 < erik-etsuji-kato> tks all 10:01 < btckid> thank you all 10:01 < tarun> thank you. 10:01 < glozow> larryruane: do you know of any applications where you share an input with an untrusted counterparty who might be able to broadcast with a different witness to grief you? 10:01 < brunoerg> thank you 10:01 < stickies-v> ty for hosting and for the very detailed notes and questions, larryruane ! 10:01 < OliverOffing> thanks larryruane and thanks all 10:01 < glozow> thanks for hosting larryruane! 10:01 -!- OliverOffing [~OliverOff@189.1.174.14] has quit [Quit: Connection closed] 10:01 < larryruane> #endmeeting 10:01 < glozow> next week is libsecp week :) 10:01 < monlovesmango> thank you!! 10:01 < svav> Thanks larryruane and all! 10:01 -!- jaonoctus50 [~jaonoctus@vmi550577.contaboserver.net] has quit [Quit: Connection closed] 10:01 < theStack_> glozow: yay \o/ 10:01 < brunoerg> glozow: cool 10:02 < ziggie> thanks for hosting larry 10:02 -!- tarun [~tarun@cpe-174-97-2-41.cinci.res.rr.com] has quit [Quit: Konversation terminated!] 10:02 < lightlike> thanks larryruane 10:02 -!- Talkless [~Talkless@mail.dargis.net] has quit [Remote host closed the connection] 10:02 < btckid> glozow: +1 10:02 < glozow> you can all start prepping right away! https://bitcoincore.reviews/libsecp256k1-748 10:02 < erik-etsuji-kato> glozow: Really? That will be awesome! 10:02 < larryruane> glozow: nice! I'll be there! 10:02 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews 10:03 -!- observer71 [~observer@cpe-23-242-148-67.socal.res.rr.com] has quit [Quit: Connection closed] 10:04 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed] 10:04 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has quit [] 10:04 -!- JLPF [~JLPF@189.124.122.247] has left #bitcoin-core-pr-reviews [] 10:05 < effexzi> Thanks! 10:06 < Kaizen_Kintsugi_> Thanks for hosting larry and thanks to everyone providing insight into this, I learned a lot. 10:13 -!- btckid [~btckid@189.236.6.29] has quit [Ping timeout: 256 seconds] 10:15 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews 10:15 -!- aferreira44 [~aferreira@177.220.174.62] has quit [Quit: Connection closed] 10:24 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4dhoiqoswm06o.ipv6.telus.net] has quit [Remote host closed the connection] 10:24 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has quit [Remote host closed the connection] 10:25 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4dhoiqoswm06o.ipv6.telus.net] has joined #bitcoin-core-pr-reviews 10:33 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has joined #bitcoin-core-pr-reviews 10:34 -!- luke-jr [~luke-jr@user/luke-jr] has joined #bitcoin-core-pr-reviews 10:37 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4dhoiqoswm06o.ipv6.telus.net] has quit [Ping timeout: 250 seconds] 10:46 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4dhoiqoswm06o.ipv6.telus.net] has joined #bitcoin-core-pr-reviews 10:49 -!- gleb7454386 [~gleb@178.150.137.228] has joined #bitcoin-core-pr-reviews 10:57 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4dhoiqoswm06o.ipv6.telus.net] has quit [Ping timeout: 260 seconds] 11:06 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has quit [Remote host closed the connection] 11:13 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4dhoiqoswm06o.ipv6.telus.net] has joined #bitcoin-core-pr-reviews 11:15 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4dhoiqoswm06o.ipv6.telus.net] has quit [Remote host closed the connection] 11:16 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4dhoiqoswm06o.ipv6.telus.net] has joined #bitcoin-core-pr-reviews 11:22 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has joined #bitcoin-core-pr-reviews 11:26 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has quit [Ping timeout: 240 seconds] 11:50 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has joined #bitcoin-core-pr-reviews 11:54 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has quit [Ping timeout: 240 seconds] 12:00 -!- brunoerg [~brunoerg@187.183.47.88] has joined #bitcoin-core-pr-reviews 12:12 -!- oopsydanger [uid536846@id-536846.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity] 12:14 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.] 12:15 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews 12:16 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Client Quit] 12:16 -!- BitFlib [~BitFlib@185.209.196.162] has joined #bitcoin-core-pr-reviews 12:17 -!- BitFlib [~BitFlib@185.209.196.162] has quit [Client Quit] 12:17 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews 12:17 -!- BitFlib [~BitFlib@185.209.196.162] has joined #bitcoin-core-pr-reviews 12:19 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!] 12:40 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity] 12:49 -!- sanya [~sanya@178-223-17-164.dynamic.isp.telekom.rs] has quit [Quit: Connection closed] 13:02 -!- brunoerg [~brunoerg@187.183.47.88] has quit [Ping timeout: 268 seconds] 13:04 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Ping timeout: 256 seconds] 13:08 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has joined #bitcoin-core-pr-reviews 13:28 -!- BitFlib [~BitFlib@185.209.196.162] has quit [Quit: Leaving.] 14:13 -!- robertspigler [~robertspi@2001:470:69fc:105::2d53] has quit [Quit: Client limit exceeded: 20000] 14:13 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has quit [Ping timeout: 260 seconds] 14:17 -!- gleb7454386 [~gleb@178.150.137.228] has quit [Ping timeout: 240 seconds] 14:19 -!- gleb7454386 [~gleb@178.150.137.228] has joined #bitcoin-core-pr-reviews 14:43 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has joined #bitcoin-core-pr-reviews 14:46 -!- lukedashjr [~luke-jr@user/luke-jr] has joined #bitcoin-core-pr-reviews 14:47 -!- jnewbery [~john@user/jnewbery] has quit [Ping timeout: 256 seconds] 14:47 -!- jnewbery [~john@user/jnewbery] has joined #bitcoin-core-pr-reviews 14:49 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 250 seconds] 14:49 -!- lukedashjr is now known as luke-jr 15:20 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 15:47 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has quit [Ping timeout: 268 seconds] 15:48 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has joined #bitcoin-core-pr-reviews 15:53 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has quit [Ping timeout: 250 seconds] 15:59 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has joined #bitcoin-core-pr-reviews 17:03 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has quit [Ping timeout: 240 seconds] 17:05 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has joined #bitcoin-core-pr-reviews 17:06 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has quit [Remote host closed the connection] 17:07 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has joined #bitcoin-core-pr-reviews 17:08 -!- docallag [~docallag@2a02:8084:90e2:3a80:609d:4ae9:41c6:f17c] has quit [Ping timeout: 240 seconds] 17:12 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has joined #bitcoin-core-pr-reviews 17:16 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has quit [Ping timeout: 268 seconds] 17:22 -!- brunoerg [~brunoerg@187.183.47.88] has joined #bitcoin-core-pr-reviews 17:25 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 17:33 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has joined #bitcoin-core-pr-reviews 18:26 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4dhoiqoswm06o.ipv6.telus.net] has quit [Remote host closed the connection] 18:26 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4dhoiqoswm06o.ipv6.telus.net] has joined #bitcoin-core-pr-reviews 18:27 -!- brunoerg [~brunoerg@187.183.47.88] has quit [Ping timeout: 256 seconds] 18:31 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4dhoiqoswm06o.ipv6.telus.net] has quit [Ping timeout: 250 seconds] 18:33 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has joined #bitcoin-core-pr-reviews 18:38 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has quit [Ping timeout: 268 seconds] 18:39 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has joined #bitcoin-core-pr-reviews 18:44 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has quit [Ping timeout: 240 seconds] 18:44 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4dhoiqoswm06o.ipv6.telus.net] has joined #bitcoin-core-pr-reviews 18:52 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has joined #bitcoin-core-pr-reviews 19:47 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4dhoiqoswm06o.ipv6.telus.net] has quit [Ping timeout: 240 seconds] 19:57 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has quit [Ping timeout: 250 seconds] 20:03 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:4178:22ae:f494:3f2] has joined #bitcoin-core-pr-reviews 20:24 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te55qu5d65v1opg.ipv6.telus.net] has joined #bitcoin-core-pr-reviews 21:01 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 21:28 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te55qu5d65v1opg.ipv6.telus.net] has quit [Ping timeout: 250 seconds] 21:41 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te55qu5d65v1opg.ipv6.telus.net] has joined #bitcoin-core-pr-reviews 21:46 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te55qu5d65v1opg.ipv6.telus.net] has quit [Ping timeout: 240 seconds] 22:00 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te55qu5d65v1opg.ipv6.telus.net] has joined #bitcoin-core-pr-reviews 23:04 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te55qu5d65v1opg.ipv6.telus.net] has quit [Ping timeout: 250 seconds] 23:33 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te55qu5d65v1opg.ipv6.telus.net] has joined #bitcoin-core-pr-reviews --- Log closed Thu Jan 27 00:00:42 2022