--- Log opened Mon Feb 03 00:00:28 2020
04:31 -!- waxwing [~waxwing@193.29.57.116] has quit [Remote host closed the connection]
04:32 -!- waxwing [~waxwing@193.29.57.116] has joined ##ctv-bip-review
04:33 -!- waxwing [~waxwing@193.29.57.116] has quit [Remote host closed the connection]
04:34 -!- waxwing [~waxwing@193.29.57.116] has joined ##ctv-bip-review
04:36 -!- waxwing [~waxwing@193.29.57.116] has quit [Remote host closed the connection]
04:36 -!- waxwing [~waxwing@193.29.57.116] has joined ##ctv-bip-review
07:24 -!- cryptomortis [~uid176982@li421-223.members.linode.com] has joined ##ctv-bip-review
07:38 -!- brandon[m]1 [brandongwu@gateway/shell/matrix.org/x-olzzhmkkzwqqstjj] has joined ##ctv-bip-review
07:38 -!- brandon[m]1 is now known as brandon[m]2
07:44 -!- brandon[m]2 is now known as brandoncurtis
07:54 -!- brandoncurtis [brandongwu@gateway/shell/matrix.org/x-olzzhmkkzwqqstjj] has quit [Quit: authenticating]
07:57 -!- brandoncurtis [brandongwu@gateway/shell/matrix.org/x-pgbecwfooebcdhbq] has joined ##ctv-bip-review
08:18 -!- brandoncurtis [brandongwu@gateway/shell/matrix.org/x-pgbecwfooebcdhbq] has left ##ctv-bip-review []
08:18 -!- brandoncurtis [brandongwu@gateway/shell/matrix.org/x-pgbecwfooebcdhbq] has joined ##ctv-bip-review
09:40 < brandoncurtis> Thoughts on additional questions or concerns that could be addressed e.g. on utxos.org, given discussions at Saturday's workshop?
09:46 < jeremyrubin> ?
10:26 -!- jeremyrubin [~jr@c-67-180-60-249.hsd1.ca.comcast.net] has quit [Remote host closed the connection]
11:32 < kanzure> guess not
12:52 -!- jeremyrubin [~jr@c-67-180-60-249.hsd1.ca.comcast.net] has joined ##ctv-bip-review
13:31 < jeremyrubin> I just wasn't sure what the question was
13:34 < jeremyrubin> utxos.org is open source btw https://github.com/JeremyRubin/utxos.org
13:34 < jeremyrubin> if anyone wants to suggest adding stuff (I need to link in the workshop transcripts and stuff)
13:39 < jeremyrubin> I need to send up some workshop follow ups
14:11 < brandoncurtis> ah sorry, I was implying that we could add anything we thought might be helpful to utxos.org, and that could include responses to questions or criticisms that came up during the workshop
15:47 -!- jeremyrubin [~jr@c-67-180-60-249.hsd1.ca.comcast.net] has quit [Ping timeout: 265 seconds]
16:40 < brandoncurtis> "what about presigned keys for <proposed use case>" came up a lot, so I was thinking about contributing something along those lines to augment the Alternatives page
18:22 < bsm1175321> I'm more concerned about <any covenant mechanism> for <vault based wallets>.
18:22 < bsm1175321> Deleted keys leave a lot to be desired, but if <vault based wallets> is to be the motivating factor for CTV, I think we have a lot of work to do still to demonstrate it.
18:30 < bsm1175321> If we really want to do deleted keys *right*, we should be lobbying for Schnorr signatures to have a way to not commit to pubkeys, so that pubkeys can be computed using key recovery ("provably unknown privkeys" -- rather than known-but-deleteD)
18:31 < bsm1175321> And NOINPUT, which is also required for that idea since txids commit to addresses which commit to pubkeys, even if the signature algorithm doesn't. (and is why this idea doesn't work with ECDSA signatures)
19:00 -!- jeremyrubin [~jr@c-67-180-60-249.hsd1.ca.comcast.net] has joined ##ctv-bip-review
19:10 < jeremyrubin> So I personally feel that presigned doesn't really satisfy enough of the features of every other alternative mentioned to deserve mention in the alternatives section of the page
19:10 < bsm1175321> That's extreme.
19:10 < jeremyrubin> Presigned txns are covered in detail in the optech article
19:10 < jeremyrubin> https://utxos.org/analysis/optech/
19:10 < bsm1175321> What "requirement" don't they satisfy?
19:10 < bsm1175321> err..."feature"
19:11 < jeremyrubin> And they're mentioned in the BIP as well
19:13 < jeremyrubin> So it's not like they're not mentioned anywhere on the page
19:15 < bsm1175321> Put whatever you want on your webpage...but if you don't make a clear argument, it's not going to be convincing, and omission is not a tool that's useful in that regard.
19:15 < jeremyrubin> Presigneds aren't really a substitute for any of the other mechanisms mentioned because they have a strong intereactivity assumption or device trust assumption which none of the other mechanisms have. This precludes them from being used in a composable way, or non interactive way. It also makes them un-auditable to third parties
19:16 < bsm1175321> Vault-based wallets are single-user/single-entity constructions. non-interactivity is not necessarily a requirement.
19:16 < jeremyrubin> So on the alternatives page I've tried to only include the things that meet this threshold
19:16 < jeremyrubin> Otherwise I'd add rootstock, liquid, and other side chains too
19:16 < jeremyrubin> Non-interactivity and exterior auditability are a requirement for vaults IMO
19:18 < jeremyrubin> If I'm using a vault to disperse my estate, my survivors need to be able to prove to the IRS when they had access to the funds
19:18 < bsm1175321> IMHO if you want to define such "requirements" then do so, and show how CTV is the optimal solution, instead of "CTV can also be used for..."
19:18 < bsm1175321> (and, I agree with your criticisms above)
19:20 < bsm1175321> FWIW just got off a plane, saw your mail, will read carefully tomorrow.
19:21 < jeremyrubin> As noted, pre signed mechanisms are linked to in the BIP and discussed why they are insufficient for CTV functionality
19:21 < bsm1175321> Define functionality first...
19:21 < jeremyrubin> If you want, I can add a list of requirements to the alternatives page
19:22 < bsm1175321> "insufficient for CTV" is defining your opcode as the requirement. You need to go the other way...
19:22 < jeremyrubin> covering the full breadth of things discussed above
19:22 < jeremyrubin> please re-review the BIP
19:23 < bsm1175321> I've reviewed it several times.
19:23 < jeremyrubin> Non interactivity is key for being able to use this stuff for noninteractive payment channels
19:23 < bsm1175321> Different use cases may require different solutions.
19:24 < bsm1175321> And as I mentioned in the workshop, you DO have interactivity. You can't send funds period without some amount of interactivity.
19:24 < jeremyrubin> I mean I feel like you're acting like I've been intellectually dishonest here, but presigneds are discussed in numerous places in the BIP and the online coordination is the reason
19:24 < jeremyrubin> PKI model pre-supposes a known directory of keys
19:24 < jeremyrubin> and is a common assumption
19:25 < bsm1175321> Not at all.
19:25 < bsm1175321> (I don't feel you're being dishonest in any way)
19:26 < bsm1175321> But I feel you're making a common mistake of trying to convince people about CTV by doing anything and everything with it, when you'd be better served by being more narrow.
19:26 < jeremyrubin> Too hot, too cold -- people criticized earlier it couldn't do enough and wasn't worth reviewing
19:27 < bsm1175321> When faced with criticism, you segue to "there's this other thing you can do". But instead you should be making a narrow case and showing that CTV is optimal.
19:27 < bsm1175321> Eh, I can imagine, though I didn't see that.
19:27 < jeremyrubin> Can you give an example?
19:27 < bsm1175321> Well, the laundry list of use cases is evidence enough.
19:27 < bsm1175321> CTV is a "solution in search of a problem" -- which is a problem in itself.
19:28 < bsm1175321> And you don't want to be seen that way.
19:28 < jeremyrubin> evidence that I'm skirting answering peoples actual questions?
19:28 < jeremyrubin> That's absolutely incorrect
19:28 < bsm1175321> I wouldn't say you skirted.
19:28 < jeremyrubin> I am trying to design congestion control in Bitcoin for like 3 + years
19:28 < jeremyrubin> I've gone through numerous design cycles, CTV is basically the optimal design for that
19:29 < jeremyrubin> It also works great with L2 protocols, further reducing congestion
19:29 < jeremyrubin> That's the prime use IMO
19:29 < bsm1175321> Well if congestion control is the optimal case, what would sell it is exchange-type operations who raise their hands in support, IMHO.
19:29 < jeremyrubin> Other people like vaults, CTV is pretty good for those too
19:30 < jeremyrubin> Exchanges are generally in support, but not wanting to tip the scales on btc development IMO given history of s2x
19:30 < bsm1175321> The way I see it, it's maybe a benefit, if fee rates are oscillating. If not, it's an absolutely unnecessary expense.
19:30 < bsm1175321> Aaaahhhh that's a nasty circle there.
19:30 < bsm1175321> Even if it is a benefit, it's at best a factor of 2.
19:30 < jeremyrubin> What?
19:31 < bsm1175321> Payment channels are better.
19:31 < jeremyrubin> Where does 2 come from?
19:31 < bsm1175321> It absolutely does not increase throughput.
19:31 < bsm1175321> It decreases it.
19:31 < jeremyrubin> That's not true
19:31 < bsm1175321> The most interesting thing for me from the workshop was the notion that it makes the fee market a "dark" market, sort-of.
19:31 < jeremyrubin> It absolutely increases throughput; by making it possible to batch more efficiently
19:32 < bsm1175321> There is absolutely an overhead. If all blocks are full, it's a net negative.
19:32 < jeremyrubin> Otherwise exchanges can't use batching during high fee periods with low priority txns
19:32 < jeremyrubin> so they have to split txns up into different fee bands
19:32 < bsm1175321> Again, only works if there exist a low-fee period. If all blocks are full...
19:32 < jeremyrubin> No this is not true
19:32 < jeremyrubin> this behavior happens at any time
19:33 < jeremyrubin> Batching today only works if outputs are roughly the same priority
19:33 < jeremyrubin> Otherwise, you split them into batches of equal priority
19:33 < bsm1175321> Batching reduces the on-chain data load. your payment trees are an absolute increase in on-chain data load.
19:34 < jeremyrubin> You're comparing optimal batching to normal CTV
19:34 < jeremyrubin> Optimal batching is a spherical cow
19:34 < jeremyrubin> Compare actual batching and incetives
19:34 < bsm1175321> Any batching of combining two withdrawals into one is a reduction in data load.
19:34 < jeremyrubin> unless you presuppose equal priority of all outputs, batching has even more overhead
19:40 < jeremyrubin> CTV lets you structure "priority optimized" batches by grouping outputs with similar priority together in the tree
19:40 < jeremyrubin> CTV priority optimizing should have less overhead than normal batching priority grouping because you elide signatures
19:45 < bsm1175321> I've been dreaming for 2 days now of a way to elide the entire wallet structure....
19:45 < bsm1175321> vault-based wallets need a "receiving" wallet as well as a "withdrawal" wallet, and whatever comes in the middle.
19:46 < bsm1175321> It would be super awesome to be able to elide all of that and make it look like receives went directly to withdrawals with as few on-chain intermediate steps as possible.
19:46 < bsm1175321> I think it's possible...still pondering...
--- Log closed Tue Feb 04 00:00:30 2020