<c​atduck101:matrix.org> .merges

<b​inarybaron:matrix.org> what is tx_extra going to be limited to with the next hardfork?

tx_extra is gonna get limited more?

<b​inarybaron:matrix.org> I thought so

tx_extra is already limited

<b​inarybaron:matrix.org> I think its only a tx relay policy limit, not consensus.

well if everyone believes in it, it is consensus

it's limited to about 1060 bytes

<b​inarybaron:matrix.org> That seems correct, thanks

<b​inarybaron:matrix.org> I'm trying to transmit around 170 bytes of arbitrary bytes to someone who has the view keys to a Monero wallet to which I have the view keys as well. My current approach would be to encrypt the message with the public view key.

<b​inarybaron:matrix.org> Probably with ECDH (compute shared secret point with random r) -> KDF (derive symmetric key) -> ChaCha20-Poly1305 (encrypt the message) ?

<b​inarybaron:matrix.org> Is there an easier way? Payment IDs are pretty similar to what I am trying to do but they are deprecated and limited to 32 bytes.

limited to 8 bytes*

the 8-byte new payment IDs use a XOR cipher i think

<b​inarybaron:matrix.org> The deprecated (unencrypted) payment IDs are limited to 32 bytes: github.com/monero-oxide/monero-oxid…o-oxide/wallet/src/extra.rs#L36-L41

ah yeah that's true

what's the use case for this anyway?

<b​inarybaron:matrix.org> Ah, so I could just use per-transaction secret (r) ? that seems a lot simpler

may i ask?

<b​inarybaron:matrix.org> This is for our atomic swap protocol. The taker needs to transmit a certain secret (adaptor signature) to the maker at a certain point during the swap. Currently we do this over our P2P networking protocol over Tor with hidden services but they fail more often than you'd think. Taker and maker already have a shared Monero wallet (both have the view key) so my idea is that we can u<clipped message>

<b​inarybaron:matrix.org> se it to transmit the adaptor signature "over the blockchain". It's the last step that requires an active connection and interactivity (except for the swap negotiation at the start).

<b​inarybaron:matrix.org> It is a bit of a hack but I think it'd increase reliability substantially

<b​inarybaron:matrix.org> (github.com/eigenwallet/core)

<r​ucknium:monero.social> binarybaron: Is a description of the new atomic swap protocol available?

<b​illycipher:matrix.org> Hey guys, I’m able to see yalls messages even tho my home server is matrix?

isn't that how it works?

<b​illycipher:matrix.org> In the description it says “Matrix .org users can not receive PM's / see messages from several home servers (including Monero .social). Please consider using a non-Matrix .org account” my bad, it’s my first time using this

<o​frnxmr:xmr.mx> Old, needs update

ACK

<b​inarybaron:matrix.org> It is based on arxiv.org/abs/2101.12332 but with a few modifications. We are a fork of the MVP developed by COMIT. Mostly a few protocol features that require good-will from the other party:

<b​inarybaron:matrix.org> 1. Maker can allow a refund before the refund timelock expires (tx_btc_early_refund)

<b​inarybaron:matrix.org> 2. Maker can allow taker to redeem Monero even after the punish timelock expires (cooperative_xmr_redeem)

<b​inarybaron:matrix.org> 3. Some protocol changes to protect against DOS risks (partial_refund)

<b​inarybaron:matrix.org> We also made a few modifications that make the whole things more resilient but those are mostly implementation details:

<b​inarybaron:matrix.org> 1. We scan the the multi-sig wallet instead of requiring an out proof to be transmitted over the network (to reduce the need for interactivity)

<b​inarybaron:matrix.org> 2. Built in hidden-services with Arti

<b​inarybaron:matrix.org> 3. Replaced monero-wallet-rpc with FFI to wallet2, we also use monero-oxide for a bunch of stuff

<b​inarybaron:matrix.org> 4. Rewrote the entire networking and peer discovery stack

<b​inarybaron:matrix.org> A few of them (some of which haven't been implemented yet) are written down here: github.com/eigenwallet/protocol. But mostly the code is the source of truth for the protocol spec.

<b​inarybaron:matrix.org> at its core its the same protocol as the one implemented by farcaster

<b​inarybaron:matrix.org> You can read through this if you want to understand how it works. The state machine is fairly high level: github.com/eigenwallet/core/blob/master/swap/src/protocol/bob/swap.rs

the soft-limits that exist on relay were just made hard on tx verification and inclusion post FCMP++