01:55:46 <UkoeHB> New PRs for upstreaming seraphis: #9196 (crypto utils), #9197 (hash functions), #9198 (blake2b)
14:56:23 <m-relay> <t​widtwo:matrix.org> I just finished research into implementing drivechain on monero this is the link to the research if you want to check it out.
14:56:24 <m-relay> <t​widtwo:matrix.org> https://github.com/BrandyJSon/drivechain-xmr-research/blob/main/Application%20of%20drivechain%20to%20monero.pdf
15:53:20 <plowsof> Twidtwo is this incompatible with the recent relay rule for reducing the size of tx extra?
17:12:21 <m-relay> <t​widtwo:matrix.org> Missed that change. Luckily 465 bytes is enough for each message except for the 2BYTE_BUNLDE_ACK in the case there are more then 215 active sidechains and one of them has more then 256 proposed bundles. I apologize for the oversight.
19:03:30 <plowsof> Kayabanerve ^ tx extra still allows.for 456 bytes of "scripting space"? 
20:19:36 <m-relay> <t​widtwo:matrix.org> This is the thread I was basing my answer off of https://github.com/monero-project/monero/pull/8733
20:19:36 <m-relay> <t​widtwo:matrix.org> 456 bytes is assuming the transaction has 16 outputs. 1060 bytes is the the technical max length of tx extra that will get relayed.
23:45:09 <m-relay> <k​ayabanerve:matrix.org> plowsof: Data space. Monero doesn't execute any of it.
23:45:39 <m-relay> <k​ayabanerve:matrix.org> If you define an off-chain protocol for it, that doesn't make Monero have scripting. That makes you using Monero for data transport for your script engine.
23:48:10 <m-relay> <k​ayabanerve:matrix.org> This proposal would add scripting to TX extra.
23:50:27 <m-relay> <k​ayabanerve:matrix.org> I find Drivechains as a whole a flawed idea. I don't support adding this level of scripting to TX extra. Any scripting added should be enough all future applications can be built be recursive instantiations of the fundamental script. This absolutely fails to do that.
23:54:08 <m-relay> <k​ayabanerve:matrix.org> I'm also not convinced of some of the discussions in this paper (under "Further Research").
23:59:37 <m-relay> <k​ayabanerve:matrix.org> The techniques https://github.com/monero-project/research-lab/issues/116 culminates in would offer soundness guarantees, not require nodes run additional other nodes, and have full privacy across the SC pool (if added with a dedicated pool which didn't supersede the entire flow, as proposed). That fixes the miner voting concerns, reduces computational load if dome correctly, doesn<clipped message>
23:59:37 <m-relay> <k​ayabanerve:matrix.org> 't require miners vote on which apps to validate, and doesn't lose privacy when discussing which sidechain/app was interacted with.