--- Log opened Tue Nov 12 00:00:05 2019
01:04 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Ping timeout: 245 seconds]
01:46 -!- jonatack [~jon@134.19.179.203] has joined #bitmetas
02:52 -!- jeremyrubin [~jr@c-67-180-60-249.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds]
06:26 -!- jonatack [~jon@134.19.179.203] has quit [Quit: jonatack]
06:26 -!- jonatack [~jon@134.19.179.203] has joined #bitmetas
06:51 -!- jonatack [~jon@134.19.179.203] has quit [Ping timeout: 276 seconds]
08:37 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined #bitmetas
10:22 -!- jeremyrubin [~jr@c-67-180-60-249.hsd1.ca.comcast.net] has joined #bitmetas
11:25 < jeremyrubin> If you care what OP_SECURETHEBAG is named you can vote in this poll here: https://twitter.com/JeremyRubin/status/1194328933342146560
11:26  * aj google searches for twitter spam farms
11:26 < jonatack> :D
11:26 < jeremyrubin> Well, I guess I'm just glad you care that much
11:32 < aj> jeremyrubin: you might find https://gist.github.com/ajtowns/dc9a59cf0a200bd1f9e6fb569f76f7a0 an amusing thought experiment use case for OP_COSHV btw
11:32 < sipa> i liked COSHV
11:33 < jeremyrubin> Haha you should have chimed up more at the bitdevs meetup! everyone was crapping on the name there
11:33 < jeremyrubin> Unfortunately it became no longer technically accurate 
11:33 < sipa> yeah i know
11:33 < sipa> but secure the bag isn't clearwr
11:33  * jeremyrubin ponders, is saying everyone a violation of CHR? is saying what someone didn't say a violation of CHR?
11:34 < sipa> haha, i don't think so
11:36 < aj> sipa: i think pyskell's existing uses don't overlap tagged hashes question got missed?
11:36 < jeremyrubin> aj: yes, very cool
11:36 < jeremyrubin> gmax and I had a convo about this a while back
11:37 < sipa> aj: which?
11:38 < jeremyrubin> aj: did you watch my SB TLV talk?
11:38 < jeremyrubin> There's some stuff about non-interactive LN channel opens which is really cool for being able to do this
11:39 < nickler> jeremyrubin: what's the most up to date resource on STB? I thought it *was* checkoutputshashverify.
11:39 < aj> jeremyrubin: ugh, no, those dropped off my todo list and i forgot :(
11:40 < jeremyrubin> https://docs.google.com/presentation/d/1p9Q-pmx-NnjXWMDPtSoQdLkLE1l5XPOGiXdTcq8od0w
11:40 < jeremyrubin> slide 39 and slide 35 are relevant
11:41 < nickler> jeremyrubin: thanks
11:41 < jeremyrubin> nickler: it's been called OP_SECURETHEBAG for ~5-6 months? It was called OP_COSHV for like 2 weeks... but some folks refused to use the new name, even though the old name was deprecated primarily for technical reasons
11:42 < jeremyrubin> nickler: if there weren't a technical reason for the change, I would have resisted changing the name as well. This is also why it was COSHV and not COHV, because it was critical to emphasize it was all outputs and not just one singular, but people griped on that too
11:43 < aj> (fwiw, i think SECURETHEBAG is fun and fine for a thought experiment, but completely inconsistent with everything else in script so should become boring for the actual proposal. but it's just a name, so whatever)
11:43 < jeremyrubin> What's that expression.... There are only two hard problems in computer science: Cache invalidation, naming things, and off-by-one errors
11:50 < jeremyrubin> nickler: https://github.com/JeremyRubin/bips/blob/op-secure-the-bag/bip-secure-the-bag.mediawiki
11:54 < jeremyrubin> aj: RE https://twitter.com/ajtowns/status/1194336731786436608, on the flags the current opcode is only defined to check anything if it's exactly 32 bytes. This leaves open an easy upgrade path for a flags field. E.g., I could imagine wanting to pass a inputs/outputs bitmask eventually.
12:04 < aj> yeah, think i vaguely remember seeing that at some point
13:46 < nickler> jeremyrubin: do I read it correctly that this wouldn't allow anything new if there's already anyprevout (using the signature-in-scriptPubKey trick)?
14:02 < jeremyrubin> It depends, it might be an explicity disabled thing if anyprevout is only enabled for schnorr 
14:03 < jeremyrubin> it's also cheaper to do than anyprevout, both in space and in time to verify
14:04 < jeremyrubin> but feature wise, I think it should be a strict subset. But that's by design
14:07 < jeremyrubin> So if you strongly expect anyprevout to get in for ecdsa, and you don't care for efficiency gains, then you should probably *not* review securethebag.
14:08 < jeremyrubin> But, I would argue that you should review OP_SECURETHEBAG even in that case because the arguments for/against securethebag do mention why anyprevout pubkey recovery might be undesirable
14:09 < jeremyrubin> E.g. this hypothesis which I shared on the mailing list:
14:09 < jeremyrubin> H: There is no set of pure extensions* to script E such that enabling E and OP_SECURETHEBAG as proposed enables recursive covenants, but E alone does not enable recursive covenants?
14:09 < jeremyrubin> * Of course there are things that specifically are specifically designed to switch on if OP_SECURETHEBAG, so pure means normal things like OP_CAT that are a function of the arguments on the stack or hashed txn data. 
14:10 < jeremyrubin> This sort of hypothesis fails for anyprevout, where ECTWEAK and OP_CAT can introduce much more behavior than might otherwise be expected
14:21 < nickler> Pubkey recovery is not required for the trick I mentioned. I don't see how STB applies to "ecdsa" if it's a tapscript opcode (which I don't care much about anyway). You talk about SECURETHEBAG being useful in channel factories, but they're only remotely realistic with anyprevout anyway.
14:21 < nickler> I don't get how ECTWEAK or OP_CAT is a problem with signature-in-scriptpubkey.
14:21 < nickler> sure STB is more efficient
14:21 < jeremyrubin> I thought it is?
14:21 < jeremyrubin> What's the trick then?
14:22 < jeremyrubin> nickler: can you read the BIP draft I linked, it's an OP_NOP
14:22 < jeremyrubin> nickler: and that's incorrect w.r.t. channel factories being not useful.
14:23 < jeremyrubin> unless you have a definition of 'useful' which requires anyprevout
14:23 < jeremyrubin> You can non-interactively open a tree of channels to as many people as you like, and immediately begin paying them without them having a key online
14:24 < nickler> You create a public key, sign the transaction you want to spend the output with and have a scriptpubkey <sig> <pk> checksig. Given the transaction anyone can verify that the output can only spend that way
14:24 < nickler> I never said channel factories are not useful?
14:25 < jeremyrubin> YOu said it's not useful for the SECURETHEBAG style channel factories
14:25 < nickler> I'm saying channel factories require anyprevout
14:25 < jeremyrubin> What are channel factories?
14:25 < jeremyrubin> The securethebag style ones just require multisig, securethebag just makes it more efficient
14:26 < jeremyrubin> nickler: I think that trick doesn't work, IIRC for anyprevout you're still signing the script itself
14:27 < jeremyrubin> just not the txid
14:27 < jeremyrubin> So you can't sign a signature
14:27 < nickler> there's anyprevoutanyscript
14:28 < nickler> I thought that multiparty channels without eltoo style channels are extremely difficult to implement. But perhaps we're talking about a different concept of multiparty channels.
14:28 < jeremyrubin> Probably we're talking about something different
14:31 < jeremyrubin> If you have anyprevout and anyscript, I guess that should work?
14:36 < jeremyrubin> You also need a chaperone in there then too right?
14:36 < jeremyrubin> And then with this technique you lose the ability to prune the interior node data since the signatures are important
14:36 < nickler> if chaperones become a thing, yes (mailing list on that seems like light reject)
14:39 < nickler> would be useful to have a comparison in the bip since you mention anyprevout anyway
14:39 < jeremyrubin> with securethebag all the interior node data is basically deterministic from the leaves, so your node can safely prune & recompute it for relay/storage. 
14:41 < jeremyrubin> I was unaware of the trick that you mentioned so it didn't appear. It doesn't work with just anyprevout or noinput unless you do the checksigfromstack type stuff and PKR?
14:42 < nickler> right re determinism
14:43 < jeremyrubin> I guess if the PK that you use is just publicly known to all nodes that's not true
14:43 < nickler> Why doesn't it work with bip-anyprevout? It also specifies ANYPREVOUTANYSCRIPT
14:43 < nickler> There's also randomness in the nonce, which could also be public
14:46 < nickler> but meh
14:46 < jeremyrubin> The main benefit for OP_SECURETHEBAG over this technique is basically performance/storage and that it's a much simpler change which introduces far fewer features.
14:47 < jeremyrubin> I think the implementation details themselves are basically non-controversial? 
15:24 -!- chartor [~Mutter@ppp-vpdn-37.1.85.215.yarnet.ru] has joined #bitmetas
15:31 -!- chartor [~Mutter@ppp-vpdn-37.1.85.215.yarnet.ru] has quit [Ping timeout: 265 seconds]
20:14 < aj> nickler: multiparty without eltoo is hard, because without eltoo == punishing cheaters, but if you've got multiple parties it's hard to distribute the funds fairly amongst the non-cheaters
20:15 < aj> nickler: securethebag lightning balls or whatever get around this by updating the state on chain, i think
--- Log closed Wed Nov 13 00:00:06 2019