##eltoo discussion on annex

gistfile1.txt

<instagibbs> _aj_, thinking I should have two variants of my work, one which is easier to get into signet(but also more pinnable), as well as one that's more "ideal" and can be switched on once features are in. So for MVP for standardness, I think I just need some form of annex relay support
<instagibbs> would be easy to remove EAs, could at least prioritise txns if nothing else as a demo. (or I could hack settlement txns to just dump value to fee)
<instagibbs> Shouldn't be a ton of work on my end to support both variants, and having live demo > not
* Disconnected ()
* Now talking on ##eltoo
<_aj_> instagibbs_: EAs seem fine to keep -- doesn't really matter if there's dust anyone-can-spend utxos on signet due to mempool evictions; all utxos on signet are equally worthless anyway
<instagibbs_> ok, so 1) annexcarrier option which can be arbitrarily restricted later via Bright Side PR 2) Make OP_TRUE output standard 3) allow dusty OP_TRUE. These would be quite low drag and allow me to get txns in the mempool/block
...
<_aj_> instagibbs_: yeah; for (1) hardcode some data carrier prefix for the annex that matches bips#1381?
<instagibbs_> SGTM
<_aj_> so [50] (annex) [20] (length=20, deltha=0) [.....:value]  if type=0 is uninterpreted data carrier, which i guess seems reasonable?
<_aj_> deltha? weirdo
<_aj_> or [50 ; FF ; 00 1d ; data ]  (type=0x3f, length=0x3+0x1d) per the approach in https://github.com/ariard/bips/pull/1 that doesn't use serialize.h style compressed ints
<_aj_> actually, i guess if it's delta oriented, having the "uninterpreted data" always be first, and hence type=0, makes sense. so [50 03 00 1d ..data..] (type=0x00, length=0x3+0x1d) is better
<instagibbs_> Gonna level with you I don't really know the format, give me an example of 32 byte data vs like 80
...
<_aj_> length is 0x1d+3 so for 80 bytes s/1d/4d/
<_aj_> or [50 50 80bytes...] for#1381
...
<instagibbs_> I'll go with [50 50 80bytes...] format for now, I'm fine with it getting blown away by something that has test vectors later
<_aj_> sgtm
...
...
<instagibbs_> https://github.com/bitcoin-inquisition/bitcoin/pull/22 annexcarrier option
<instagibbs_> and https://github.com/bitcoin-inquisition/bitcoin/pull/23
<instagibbs_> I'll be testing/adapting my CLN branch to whatever we end up deciding is good, i think i only have to change my annex format currently? 
<instagibbs_> People get way more confused about OP_2 vs OP_TRUE than I expected, maybe not worth it :)
<_aj_> instagibbs_: s/255/126/ in the help text too?
<instagibbs_> yep, working on making it default on rn
<instagibbs_> thinking about annex stuffing a bit more, wonder if we can do slightly better. f.e., data push annex is valid IFF all other inputs commit to empty annex push(2WU each). Policy opt-in to remove griefing
<instagibbs_> just riffing in case someone thinks of something better
<instagibbs_> introspecting a spend to see that it's a APO spend to allow it an annex(assuming we'd change APO to commit tto all annexes) is pretty obnoxious
<_aj_> instagibbs_: maybe limit annex entries to MAX_SCRIPT_ELEMENT_SIZE as a standardness constraint would make sense? the only real limit we have to publishing data within a tx is that you have to separate it with random things, like a pushdata opcode, and an annex type/length signifier is pretty similar there...
<instagibbs_> was more thinking about the "signature only commits to this index's annex" issue
<_aj_> if APO sigs commit to it, then if you're doing coinjoins/dual-funding, use an APO sig yourself?
<_aj_> seems like a v2 problem
<_aj_> v0.2 maybe?
<instagibbs_> "just migrate key derivations bro" :)
<instagibbs_> it materially changes assumptions for currently deployed things. How much? eh
<_aj_> does it, though? "i promise i'll use a key path signature; whoops i accidentally used the reveal-a-200kB-inscription path instead" ?
<instagibbs_> perhaps nothing is actually effected because coinjoins use central coordinators
<instagibbs_> even if you reveal the full taptree it can't be avoided
<instagibbs_> even if you prove there is no taptree
<_aj_> yeah, but at that point you do the "annex commits to max tx size" ?
<instagibbs_> I think that's more complex to use, but in general I've been in favor of that for quite a while
<_aj_> seems less complex than even checking everyone's taptree?
<instagibbs_> i mean, taht you can literally do now
<instagibbs_> which goes back to my original question of how to not break these assumptions for people not aware/able to use annex
<_aj_> i don't really think you can? if you don't keep up with standardness/consensus changes, an untrusted counterparty will often be able to give you a tx that won't confirm when you expect it to/
<instagibbs_> think we can do better than that; not a blocker for signet anyways