--- Log opened Mon Apr 18 00:00:58 2022
00:48 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has joined #bitcoin-wizards
01:02 -!- tromp [~textual@dhcp-077-249-230-040.chello.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
01:36 -!- duderonomy [~duderonom@c-73-158-190-156.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
01:43 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 240 seconds]
01:44 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-wizards
02:04 -!- kexkey [~kexkey@178.249.214.10] has quit [Ping timeout: 250 seconds]
02:06 -!- kexkey [~kexkey@178.249.214.26] has joined #bitcoin-wizards
02:13 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 240 seconds]
02:15 -!- tromp [~textual@dhcp-077-249-230-040.chello.nl] has joined #bitcoin-wizards
02:51 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-wizards
03:24 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 240 seconds]
03:26 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-wizards
03:53 -!- tromp [~textual@dhcp-077-249-230-040.chello.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
04:02 -!- bfsfhkacjzgcytf9 [~bfsfhkacj@user/bfsfhkacjzgcytf] has quit [Ping timeout: 256 seconds]
04:07 -!- tromp [~textual@dhcp-077-249-230-040.chello.nl] has joined #bitcoin-wizards
04:42 -!- duderonomy [~duderonom@c-73-158-190-156.hsd1.ca.comcast.net] has joined #bitcoin-wizards
04:45 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 240 seconds]
04:48 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-wizards
05:05 -!- tromp [~textual@dhcp-077-249-230-040.chello.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
05:22 -!- tromp [~textual@dhcp-077-249-230-040.chello.nl] has joined #bitcoin-wizards
05:50 -!- emcy [~emcy@user/emcy] has joined #bitcoin-wizards
05:50 -!- emcy_ [~emcy@user/emcy] has quit [Read error: Connection reset by peer]
05:57 -!- emcy [~emcy@user/emcy] has quit [Remote host closed the connection]
05:57 -!- emcy [~emcy@user/emcy] has joined #bitcoin-wizards
06:04 -!- emcy [~emcy@user/emcy] has quit [Remote host closed the connection]
06:05 -!- emcy [~emcy@user/emcy] has joined #bitcoin-wizards
06:12 -!- emcy [~emcy@user/emcy] has quit [Read error: Connection reset by peer]
06:12 -!- emcy [~emcy@user/emcy] has joined #bitcoin-wizards
06:20 -!- emcy [~emcy@user/emcy] has quit [Read error: Connection reset by peer]
06:20 -!- emcy [~emcy@user/emcy] has joined #bitcoin-wizards
06:27 -!- emcy [~emcy@user/emcy] has quit [Remote host closed the connection]
06:28 -!- emcy [~emcy@user/emcy] has joined #bitcoin-wizards
06:35 -!- emcy [~emcy@user/emcy] has quit [Read error: Connection reset by peer]
06:35 -!- emcy_ [~emcy@user/emcy] has joined #bitcoin-wizards
06:44 -!- emcy [~emcy@user/emcy] has joined #bitcoin-wizards
06:44 -!- emcy_ [~emcy@user/emcy] has quit [Read error: Connection reset by peer]
07:08 -!- emcy [~emcy@user/emcy] has quit [Remote host closed the connection]
07:08 -!- emcy [~emcy@user/emcy] has joined #bitcoin-wizards
07:27 -!- emcy [~emcy@user/emcy] has quit [Read error: Connection reset by peer]
07:27 -!- emcy [~emcy@user/emcy] has joined #bitcoin-wizards
07:39 -!- solocshaw [~Thunderbi@gateway/vpn/pia/solocshaw] has joined #bitcoin-wizards
07:43 -!- tromp [~textual@dhcp-077-249-230-040.chello.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
07:44 -!- emcy_ [~emcy@user/emcy] has joined #bitcoin-wizards
07:44 -!- emcy [~emcy@user/emcy] has quit [Read error: Connection reset by peer]
07:52 -!- emcy [~emcy@user/emcy] has joined #bitcoin-wizards
07:52 -!- emcy_ [~emcy@user/emcy] has quit [Read error: Connection reset by peer]
07:59 -!- emcy_ [~emcy@user/emcy] has joined #bitcoin-wizards
08:00 -!- emcy [~emcy@user/emcy] has quit [Read error: Connection reset by peer]
08:05 -!- roconnor [~roconnor@coq/roconnor] has joined #bitcoin-wizards
08:07 -!- emcy_ [~emcy@user/emcy] has quit [Read error: Connection reset by peer]
08:07 -!- emcy [~emcy@user/emcy] has joined #bitcoin-wizards
08:25 -!- tromp [~textual@dhcp-077-249-230-040.chello.nl] has joined #bitcoin-wizards
08:54 -!- tromp [~textual@dhcp-077-249-230-040.chello.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
08:55 < pinheadmz> jeremyrubin has there been any discussion about applying BIP119 only to a new tapscript version instead of soft forking into the general script interpreter ?
08:55 < pinheadmz> just curious if that would lubricate develoepr endorsement at all
09:01 -!- tromp [~textual@dhcp-077-249-230-040.chello.nl] has joined #bitcoin-wizards
09:10 -!- solocshaw [~Thunderbi@gateway/vpn/pia/solocshaw] has quit [Ping timeout: 276 seconds]
09:15 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 240 seconds]
09:16 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-wizards
09:29 -!- bfsfhkacjzgcytf9 [~bfsfhkacj@user/bfsfhkacjzgcytf] has joined #bitcoin-wizards
09:34 -!- tromp [~textual@dhcp-077-249-230-040.chello.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
10:25 -!- tromp [~textual@dhcp-077-249-230-040.chello.nl] has joined #bitcoin-wizards
10:26 < jeremyrubin> yes, originally it was proposed as such
10:26 < jeremyrubin> however, there are applications where CTV in bare script is more efficient, so i opted to make it available in all contexts
10:27 < jeremyrubin> if we're at the stage of horse trading for political favour to promote taproot as opposed to technical reasoning, it's beyond the scope of what i'm interested to partake in
10:27 < roconnor> btw, are all such applications of bare CTV essentially just congenstion control?
10:27 < roconnor> I was having trouble thinking of anything else.
10:27 < jeremyrubin> vaults as well
10:27 < roconnor> really?
10:28 < jeremyrubin> altho personally i think you're less fee sensitive on those and likely want a TR key
10:28 < jeremyrubin> jamesob's proposal has the backbone of the vault IIRC be bare script, as with kanzures iirc
10:29 < jeremyrubin> i would have no issue removing it from bare and we can soft fork to add it later for an efficiency gain later
10:29 < roconnor> I guess I'll have to go and look at those.  I find it surprising.
10:29 < jeremyrubin> but then i also get people shouting at me that soft forks must be rarer than the rarest of rare items, so it seems to not hurt to include it
10:30 < jeremyrubin> now that taproot actually exists, it also makes CTV dependencyless, whereas before it was unclear taproot would activate
10:30 < jeremyrubin> but really there's 3 questions
10:31 < jeremyrubin> 1 ctv in bare, 2 ctv in p2sh, 3 ctv in segwit v0
10:31 < jeremyrubin> technically 2 is unusable
10:31 < jeremyrubin> but i think it's not worth it to disable 
10:32 < roconnor> for me, presonally, it is more of a question as to whether bare CTV is useful.
10:33 < roconnor> The congestion control argument is ... difficult to follow.
10:34 < roconnor> I got the impression that aj was onboard with it, so it is probably a good thing.
10:35 < jeremyrubin> what about it is hard to follow?
10:35 < jeremyrubin> (asked sincerely, maybe i can clear something up)
10:36 < jeremyrubin> 1. why anyone would want it? 2. why it works? 3. why it isn't strictly worse
10:36 < jeremyrubin> (common questions)
10:37 < roconnor> Well I understand the general premise that it might be the case that when there is a backlog you want to commit to everything up front and then slowly, among many possible redemption possibility, let the outputs appear on chain later when fees are lower, or the importance is higher.
10:38 < jeremyrubin> cool
10:39 < roconnor> But the details of how much you would save using bare ctv over taproot ctv and under what conditions, and how much you will save appears as a difficult to interpret graph generated by some program that implements some sort of analysis based on some kind of assumptions ...
10:39 < jeremyrubin> ah
10:39 < jeremyrubin> yes
10:39 < roconnor> I'm not really complaining.
10:39 < roconnor> I haven't put in the required effort.
10:39 < jeremyrubin> so i think this is an existential proof v.s. a forall proof
10:39 < roconnor> All I mean is that it is hard and seems to require that effort.
10:39 -!- PaperSword [~PaperSwor@50.126.96.22] has quit [Remote host closed the connection]
10:39 < jeremyrubin> what i've shown is there exists a reasonable circumstance where you save space doing this
10:40 < jeremyrubin> and i can characterize that circumstance to some generality 
10:40 -!- PaperSword [~PaperSwor@50.126.96.22] has joined #bitcoin-wizards
10:40 < jeremyrubin> but i can't really say if that *is* what will happen
10:40 < jeremyrubin> but this is far better than 'maybe it could be more efficient this way'
10:40 < roconnor> That's fair.  It's just that I haven't gotten even that far. ... cause I haven't really tried yet.
10:41 < jeremyrubin> forgive me if you've seen it already
10:41 < jeremyrubin> https://utxos.org/analysis/bip_simulation/
10:41 < jeremyrubin> https://utxos.org/analysis/batching_sim/
10:41 < jeremyrubin> this shows two distinct scenarios where it helps
10:41 < jeremyrubin> I have not contrasted to taproot v.s. bare here, just bare alone
10:41 < roconnor> Oh I don't think I've seen those links before.
10:41 < jeremyrubin> but i think you can intuit that with taproot it's marginally worse
10:41 < jeremyrubin> but in a space where margins are relevant 
10:42 < jeremyrubin> there are other scenarios where it help
10:42 < jeremyrubin> also i think some of these things you'd see mixed behavior
10:42 < jeremyrubin> e.g. congestion subtree with 10 people -- taproot better, as odds 10 people can sign cooperatively is high
10:42 < roconnor> I'd certianly be interested in a comparision to taproot CTV.  (not saying you have to accomidate me, but just letting you know where my concerns lie).
10:42 < jeremyrubin> cong subtree with 100 people -- bare is better, as odds 100 people can cooperate is low
10:43 < jeremyrubin> so it wouldn't be worth the taproot overhead given low P of cooperation
10:43 < roconnor> I think it also matters, to a certain extend, how much better.
10:44 < jeremyrubin> roconnor: i don't quite have the sophistication to make that judgement 
10:44 < jeremyrubin> there are a few different things that make it 'nonlinear'
10:44 < jeremyrubin> e.g., nudging the per-tx cost can make you switch from radix 4 optimal to radix 5 optimal for CTV trees that bias towards minimizing per-user cost
10:45 < jeremyrubin> so that can be a really big behavioral change which i'm not sure i know how to describe one or the other as better
10:46 -!- tromp [~textual@dhcp-077-249-230-040.chello.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
10:47 < jeremyrubin> so that's been my bias is that i can imagine scenarios where you might prefer one over the other, so I tried to give users a bit more freedom on that
10:48 < jeremyrubin> but if it were clear we should only have it in Taproot, I agree that might also mean it becomes OP_SUCCESSX with push semantic
10:48 < jeremyrubin> but you'd also have to rule out using it with segwit v0
10:48 < BlueMatt[m]> is there a realistic path from today to all wallets supporting CTV withdraw semantics, with some kind of negotiated fee penalty associated with that? I'm still incredibly dubious that there is a realistic path to the broad support needed to make these types of things usable.
10:48 < jeremyrubin> which i dont think is fair
10:49 < jeremyrubin> BlueMatt[m], yes, most of the wallet logic is already there for it
10:49 < roconnor> why would it be unfair to rule out segwit v0?
10:49 < jeremyrubin> (why can't we rule out segwit v0? still a lot of deployed ECDSA infrastructure)
10:49 < BlueMatt[m]> no, not "implemented" but "implemented in every wallet that users actively use"
10:49 < jeremyrubin> Why is that required?
10:49 < BlueMatt[m]> plus you need some kind of ability to tell the sender "hey, you can send it to me via ctv, but if you do, you need to include extra amount X cause you're costing me more fees"
10:49 < BlueMatt[m]> cause that's required for any exchange/large batch sender to deploy it?
10:50 < BlueMatt[m]> if only a small fraction of their users support it, its not worth bothering
10:50 < jeremyrubin> i would expect roll-out would happen in a more opt-in way
10:50 < jeremyrubin> for example, withdraw into lightning channel could be popular
10:51 < BlueMatt[m]> sure, but unless you get pretty large scale no one is gonna bother. there's a massive chicken-and-egg problem here
10:51 < jeremyrubin> well, can't even begin to solve it with no opcode
10:51 < BlueMatt[m]> (I'm not saying there aren't other ways to use ctv that are interesting, I'm just saying even if we had ctv tomorrow I'm incredibly dubious anyone would use the "congestion control" designs....ever)
10:51 < jeremyrubin> ah, fair
10:52 < jeremyrubin> if you review the blog, it's also the case that not everyone has to adopt it
10:52 < jeremyrubin> you get beenfit just using it selfishly
10:52 < jeremyrubin> even if you have to fully 'drive' the execution of it
10:52 < jeremyrubin> https://stephanlivera.com/episode/339/
10:53 < BlueMatt[m]> yea, I mean I get that you could deploy it partially, just for users that do support it, but I'm somewhat dubious any large batch senders would put in the engineering effort unless you had a fairly large number of users with it active
10:53 < BlueMatt[m]> and its also a pretty tough pitch for a consumer wallet, in part cause now you have to pre-negotiate an extra fee for the cost of getting the payout that way (or exchanges have some kind of two-tier withdraw fees? I dunno the ux here is a mess)
10:54 < jeremyrubin> look at "One transaction is just going to..." on, since i have a roadmap there for how i think mkt would adopt the new tech
10:54 < jeremyrubin> BlueMatt[m], well, Muun wants to use it with all their users
10:54 < jeremyrubin> Lightning Labs I believe also wants to make their pool product use it
10:55 < BlueMatt[m]> yea, if you control the receiving software and the sending software its a more compelling pitch
10:55 < jeremyrubin> Stacks also wants to use it for their staking rewards
10:55 < BlueMatt[m]> but cross-software compat is more complicated.
10:55 < BlueMatt[m]> is there any research on how often it makes sense to take the larger on-chain footprint to use ctv vs just waiting for a big batch?
10:56 < BlueMatt[m]> like, if you control the sender + recipient you dont care who shoulders the fees, you can move that around freely
10:56 < BlueMatt[m]> you just care about minimizing total fee
10:56 < jeremyrubin> well, there is a few things
10:56 < jeremyrubin> 1, it's actually, in relatively common cases, smaller on chain load
10:56 < jeremyrubin> so i think you'd always want to use that
10:56 < BlueMatt[m]> which if your batches are over a long time horizon ctv wont matter cause you can just wait, but if they arent then you'd need some kind of model for todays-fees-vs-future-fees.
10:56 < jeremyrubin> wrt to the cases where it is larger, i agree you need some sort of forecasting, sometimes. 
10:57 < jeremyrubin> if your batch is larger than a block, you *have* to use CTV for this ;)
10:57 < jeremyrubin> it also is a clear cut benefit if you want to RBF your batch
10:57 < jeremyrubin> because the current RBF rules have quadratic fee bumping issue
10:57 < BlueMatt[m]> lol sure you can also just do two batches, when you're talking that big a few extra inputs doesn't change much :p
10:57 < jeremyrubin> so just a 2-step CTV transaction is mildly larger, but saves on fees dramatically sinc eit solves RBF quadratic 
10:58 < jeremyrubin> BlueMatt[m]: it makes a gigantic difference
10:58 < jeremyrubin> the issue is latency
10:58 < BlueMatt[m]> right, but I dont think either of those are compelling - you generally never need to rbf a batch if you're a large transactor
10:59 < jeremyrubin> latency
10:59 < jeremyrubin> you start with a small batch and improve it over time
10:59 < jeremyrubin> this whole iterative batching thing
10:59 < jeremyrubin> it doesn't work in practice because of the quadratic fee bumping issue
10:59 < jeremyrubin> which CTV solves
11:00 < BlueMatt[m]> since when is fee bumping "quadratic"? You just have to increase it by the min fee each time? I'm missing something here.
11:00 < jeremyrubin> :)
11:00 < jeremyrubin> min feerate bump 
11:00 < BlueMatt[m]> sure, if you care about the very next block you need some iterative batching thing, if you care about the block after next (which is probably what you should target), then you can just cpfp is easy.
11:01 < BlueMatt[m]> yes, min feerate bump is by a concrete feerate each time, not an increasing one.
11:01 < jeremyrubin> and the txn grows, so you have to pay for replacing it
11:01 < jeremyrubin> how much fee do you have to pay more to bump a txn with n outputs to one with n+1 outputs?
11:01 < jeremyrubin> and if you do N bumps to 2N outputs, how much do you pay
11:01 < jeremyrubin> it's N^2
11:01 < BlueMatt[m]> right, I see your point. that's still pretty cheap, though, 1sat/vbyte
11:01 < BlueMatt[m]> unless you have a ton of new outputs
11:01 < BlueMatt[m]> in which case cpfp is  just as good
11:01 < jeremyrubin> it's N^2
11:02 < BlueMatt[m]> depends a lot on your flow rate.
11:02 < jeremyrubin> well, CTV removes the problem since the root txn is constant sized?
11:02 < jeremyrubin> so it's much easier to engineer for
11:03 < BlueMatt[m]> yea, makes sense. just has to have an application where (a) the recipient/sender wants to get the funds in in the very next block (but doesnt want to spend it immediately, just get it in the next block) and (b) the sender and recipient software have to be from the same vendor
11:03 < BlueMatt[m]> I'm really dubious such a use-case exists
11:03 < jeremyrubin> no it doesn't
11:03 < jeremyrubin> this benefit comes from the case where the sender confirms it in block 1 and expands it in block 2
11:03 < BlueMatt[m]> cause the only real cases where people want something in the next block are exchanges, and there you can't use a custom negotiated thing unless the exchange does a ton of eng effort to receive it......
11:03 < jeremyrubin> the user will see something pending but they can still see the UTXO
11:04 < jeremyrubin> the only software change would be to tracethrough and see that it is CTV-confirmed, for ux benefit
11:04 < BlueMatt[m]> if you just want the user to "see something pending" 0conf works great :p
11:04 < jeremyrubin> but if you don't have that it just looks unconfirmed
11:04 < jeremyrubin> but then the service provider can lock it in in the next block
11:04 < BlueMatt[m]> and avoids the entire issue with "gotta get in in the very next block"
11:04 < jeremyrubin> ....
11:04 < BlueMatt[m]> which is a totally unsustainable model irrespective of the script type
11:04 < jeremyrubin> im not sure if there is sarcasm here
11:05 < BlueMatt[m]> not really, no.
11:05 < BlueMatt[m]> like, "get my tx confirmed in the very next block" is something I
11:05 < jeremyrubin> uhhh
11:05 < BlueMatt[m]> 'm not sure we should build for
11:05 < BlueMatt[m]> its an entirely unsustainable model, really.
11:05 < jeremyrubin> someone will be confirmed in the next block
11:06 < jeremyrubin> CTV unbundles the settlement from the full reception
11:06 < jeremyrubin> which makes that market much more efficient 
11:06 < BlueMatt[m]> as for the ux benefit of giving something to users "immediately" I dont really buy its a ux benefit - 10 minutes vs 20 minutes isn't a huge difference, users expect to see it "pending" instantly cause of 0conf, even if they understand its only pending.
11:06 < jeremyrubin> since a service provider can clear liabilities much faster
11:06 < jeremyrubin> doesn't matter if next block or 2nd 
11:06 < BlueMatt[m]> well if its the 2nd your whole argument falls apart
11:06 < jeremyrubin> what
11:06 < jeremyrubin> no it doesn't
11:06 < BlueMatt[m]> they should use cpfp and block batches instead of iterative batching, no?
11:07 < jeremyrubin> you can't even rely on CPFP for this because of descendent limits
11:07 < BlueMatt[m]> oops have a call I'm 7 minutes late to
11:07 < jeremyrubin> and idk what block batches means
11:07 < jeremyrubin> and further, while CPFP might be fine, it still doesn't solve the issue if you're riding the bottom of the mempool.
11:08 < jeremyrubin> we can talk it through more later have a nice meeting!
11:10 < jeremyrubin> i think one way to think of it that is productive is not in terms of next block or future block, but that you can pick different price/latency sensitivities for confirmation and redemption ability. There is value in clearing at a higher feerate than redeeming. If you can buy that, it's what matters, as opposed to which blocks things are ultimately
11:10 < jeremyrubin> in.
11:12 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 240 seconds]
11:16 -!- Saloframes [~Saloframe@user/Saloframes] has quit [Read error: Connection reset by peer]
11:17 -!- Saloframes [~Saloframe@user/Saloframes] has joined #bitcoin-wizards
11:18 -!- boxframes_ [~Saloframe@user/Saloframes] has joined #bitcoin-wizards
11:18 -!- Saloframes [~Saloframe@user/Saloframes] has quit [Read error: Connection reset by peer]
11:19 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-wizards
11:25 -!- boxframes_ [~Saloframe@user/Saloframes] has quit [Read error: Connection reset by peer]
11:25 -!- boxframes__ [~Saloframe@user/Saloframes] has joined #bitcoin-wizards
11:33 -!- boxframes_ [~Saloframe@user/Saloframes] has joined #bitcoin-wizards
11:33 -!- boxframes__ [~Saloframe@user/Saloframes] has quit [Read error: Connection reset by peer]
12:03 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
12:39 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined #bitcoin-wizards
12:45 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-wizards
12:46 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Remote host closed the connection]
12:55 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-wizards
13:02 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Read error: Connection reset by peer]
13:03 -!- duderonomy [~duderonom@c-73-158-190-156.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
13:04 -!- luke-jr [~luke-jr@user/luke-jr] has joined #bitcoin-wizards
13:41 < BlueMatt[m]> right by "block batches" I mean "just do batches of txn per block, roughly one batch of withdraws every ten minutes". ie really just not focusing on "getting in the next block" - any model based on that is kinda broken, we've definitely seedn times where there's basically a block worth of transactions, or arguably more, that target the "next block". anything that is looking at that kinda need just needs to use lightning or
13:41 < BlueMatt[m]> credit/0conf, "next block" is not something bitcoin should ever endeavour to support or design for.
13:42 < BlueMatt[m]> I agree you can come up with some scenarios where you may want to get a confirmation during a high fee period even when paying a client using the same software as you wrote, but it just feels incredibly niche in terms of things that are worth designing entire soft forks around. There are a lot of substantially less niche use-cases for covanents that we should be focusing on way more imo.
14:55 < _aj_> "it's N^2" -- the fee rate is O(N), not O(N^2); the fee is only O(N^2) if the tx size is linear in the number of replacements you do; but it's the fee rate that tells you whether things are too expensive, not the fee. and if you are increasing the tx size, there's a threshold effect, once you're in the next block realm, you can add a child tx instead of forever replacing the same tx
14:59 -!- jonatack [jonatack@user/jonatack] has quit [Quit: Connection closed]
15:01 -!- PaperSword [~PaperSwor@50.126.96.22] has quit [Quit: Leaving]
15:01 -!- PaperSword [~PaperSwor@50.126.96.22] has joined #bitcoin-wizards
15:13 < jeremyrubin> I've literally spent almost 0 time on congestion control for the last 2 years other than as an explanatory gateway fwiw...
15:14 < jeremyrubin> but CTV is designed to work for that use case 
15:14 < jeremyrubin> but also supports many other things too
15:14 < jeremyrubin> and i think you're wrong, and my evidence is that I talk with service providers who would like to use it as described 
15:15 < jeremyrubin> if you would like to talk to those same folks, you can do that 100% and see if they're bullshitting but it's only niche if they're lying to me
15:17 < jeremyrubin> _aj_: i understood about half the sentence, but yes, the point is about a series of N updates adding N outputs ends up costing O(N^2) on the final fee rate of the last txn
15:17 < jeremyrubin> so it serves to discourage an otherwise good behavior
15:27 -!- shesek [~shesek@user/shesek] has joined #bitcoin-wizards
16:05 < _aj_> jeremyrubin: if your initial fee rate is B sats/vb, and after N RBFs you end up with a tx of size S, your fee is O( (B+N)*S ) ; but you would have paid O( B*S ) anyway, so you've only got an additional N*S, which is a proportional increase of N/B; the N^2 stuff is misleading, it's only linear extra cost in the number of replacements.
16:06 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has quit [Remote host closed the connection]
16:14 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Quit: Leaving...]
16:17 -!- Tiraspol [~Tiraspol@user/tiraspol] has quit [Ping timeout: 246 seconds]
16:17 -!- Tiraspol [~Tiraspol@c-98-220-224-193.hsd1.il.comcast.net] has joined #bitcoin-wizards
16:17 -!- Tiraspol [~Tiraspol@c-98-220-224-193.hsd1.il.comcast.net] has quit [Changing host]
16:17 -!- Tiraspol [~Tiraspol@user/tiraspol] has joined #bitcoin-wizards
16:31 -!- duderonomy [~duderonom@c-73-158-190-156.hsd1.ca.comcast.net] has joined #bitcoin-wizards
16:31 < jeremyrubin> _aj_ you're off on the math there
16:32 < jeremyrubin> your initial TX is of size M, after N updates it's of size M+N
16:32 < jeremyrubin> so you end up paying (B+N) * (M + N) 
16:32 < jeremyrubin> vs the initial BM
16:33 < jeremyrubin> or if you did final txn with no RBF, B*(M+N)
17:21 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
17:21 -!- shesek [~shesek@user/shesek] has joined #bitcoin-wizards
17:29 -!- roasbeef [~roasbeef@104.131.26.124] has quit [Quit: Lost terminal]
17:38 -!- roasbeef [~roasbeef@104.131.26.124] has joined #bitcoin-wizards
17:41 < _aj_> jeremyrubin: if you do RBF or not, your final tx is of size S = M+N, so the only difference is whether you're paying B*S or (B+N)*S
17:48 -!- vysn [~vysn@user/vysn] has joined #bitcoin-wizards
17:57 -!- boxframes_ [~Saloframe@user/Saloframes] has quit [Quit: Leaving]
18:06 -!- kexkey [~kexkey@178.249.214.26] has quit [Quit: kexkey]
18:38 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
18:38 -!- shesek [~shesek@user/shesek] has joined #bitcoin-wizards
18:55 < jeremyrubin> I think we agree 
18:56 < jeremyrubin> There is a factor of O(N) worse fees with RBF, which is overall quadratic
19:18 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
19:18 -!- shesek [~shesek@user/shesek] has joined #bitcoin-wizards
19:22 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 240 seconds]
19:25 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-wizards
19:29 < jeremyrubin> ah i should have written B(M+N) above, my error in being a bit loose. the point of keeping M and N separate is just to demarcate the start vs finish, you can plug in N = M and see
19:29 < jeremyrubin> (B+N) * 2N vs 2BN
19:40 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 240 seconds]
19:41 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-wizards
19:56 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
19:56 -!- shesek [~shesek@user/shesek] has joined #bitcoin-wizards
20:19 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
20:19 -!- shesek [~shesek@user/shesek] has joined #bitcoin-wizards
20:30 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 240 seconds]
20:33 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-wizards
20:49 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
20:49 -!- shesek [~shesek@user/shesek] has joined #bitcoin-wizards
21:05 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
21:05 -!- shesek [~shesek@user/shesek] has joined #bitcoin-wizards
21:14 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 240 seconds]
21:19 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-wizards
21:33 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 240 seconds]
21:51 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
21:51 -!- shesek [~shesek@user/shesek] has joined #bitcoin-wizards
22:02 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined #bitcoin-wizards
22:10 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
22:10 -!- shesek [~shesek@user/shesek] has joined #bitcoin-wizards
22:12 -!- geyaeb2 [~geyaeb@gateway/tor-sasl/geyaeb] has quit [Remote host closed the connection]
22:13 -!- geyaeb2 [~geyaeb@gateway/tor-sasl/geyaeb] has joined #bitcoin-wizards
22:24 -!- shesek_ [~shesek@user/shesek] has joined #bitcoin-wizards
22:25 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
22:27 -!- shesek__ [~shesek@user/shesek] has joined #bitcoin-wizards
22:30 -!- shesek_ [~shesek@user/shesek] has quit [Remote host closed the connection]
22:32 -!- shesek_ [~shesek@user/shesek] has joined #bitcoin-wizards
22:33 -!- shesek__ [~shesek@user/shesek] has quit [Remote host closed the connection]
22:36 -!- bfsfhkacjzgcytf9 [~bfsfhkacj@user/bfsfhkacjzgcytf] has quit [Ping timeout: 248 seconds]
22:41 -!- shesek_ [~shesek@user/shesek] has quit [Remote host closed the connection]
22:41 -!- shesek_ [~shesek@user/shesek] has joined #bitcoin-wizards
22:54 -!- shesek_ [~shesek@user/shesek] has quit [Remote host closed the connection]
22:54 -!- shesek_ [~shesek@user/shesek] has joined #bitcoin-wizards
23:18 -!- shesek_ [~shesek@user/shesek] has quit [Remote host closed the connection]
23:18 -!- shesek_ [~shesek@user/shesek] has joined #bitcoin-wizards
--- Log closed Tue Apr 19 00:00:59 2022