We only ban torsion on key images, right? Everything else doesn't care?

I know we clear torsion on a variety of items. Those aren't actively relevant to me so I'm only asking about torsion checks.

*also asking about the protocol and wallet2

Yes

And then we ban unreduced points/-0 yet allow deserializing unreduced scalars, yet in the modern day, we sc_check all of them to ensure they're < l]

*< l

afaik point deserialization is not checked

Uhhhhh it is the second it passes through consensus.

So you're right in that the output key is treated as a byte array despite being rct::key

Yet any rct::key we do operate with as a point...

So basically, if it's in Bulletproofs, I can treat it as a point with those 2 checks, yet if it's an output key, uint_8[32].

... right?

Like not trying to ask for confirmation just to shoot you down lol. Just realized yeah, I was not specific enough, and yes, you're right, it's not checked ;)

I *believe* everything under Rct* (base and prunable) can be point deserialized with those validity rules AND anything paired with Bulletproofs (so post-Borromean) is sc_check'd, yet I'm checking that now.

onetime addresses and ephemeral pubkeys are not deserialized during verification

for new outputs

unless I'm mistaken

Seems like it from my double checks (as ephemeral keys aren't even acked by consensus).. Thanks for confirming :)

hello, i was thinking of making a freelance website with monero as payment. does anyone know what the best way to implement an escrow service for such a site would be?

Instead of giving your address for payment, give Carol's address instead. Ask Carol, who should be trusted by both you and your counterparties.

I don't think you need to code anything for that really.

Well, not monero code anyway.

Not sure if I understand. Is Carol on the Seller side?

Carol is a trusted 3rd party who's wallet, the buyer will deposit funds too. Once everything goes as agreed by you (the seller) and the buyer, Carol releases the funds to you. All Carol needs to set up is her Monero wallet. There is no coding involved.

Carol is the escrow.

I see now. Does that mean that for every new buyer/seller interaction I would need to create a new Carol wallet or just once for everyone? And how would I go about getting such a trusted 3rd party wallet. Sorry for the many dumb questions I'm new to this '=D

I... see... If you'd create a Carol wallet, you'd most likely be a scammer. An escrow is not you, I'm sure you realize...

The whole *point* of an escrow is that it's independent.

It's a social thing, not a code thing.

Yeah that's what I thought. But how does localmonero for example do it. Why is it their Carol Wallet trusted? And where would I get such a wallet to store the Buyers funds in

The extra_padding parser stops after 254 bytes of actual data, right? It's <= 255, yet starts from 1 for the tag. There's also a varint length here, but I don't believe it's included in that length.

what? It loops from 1 to 255 and reads 1 byte per iteration

so 255 bytes

hmm, actually it can only store 254 bytes

store and load functions are inconsistent

... fun

So I'm not sure what's up there, I just wanted to confirm that if I didn't want to cause Monero

*Monero's pareser to error, I should limit my lib's data field to 254 bytes

Oh. 1 .. <= 255 is 255 bytes, right.

Except on writing 255, yeah, it becomes 256 and serialize errors.

looking at comments there, it's 255 bytes including variant tag

so variant tag + up to 254 zeros

But not the varint len, and the data itself is 254

... this does have a varint len after the tag, right?

I was pretty sure so, and have always used that assumption, but there's a comment to the contrary

there's no varint len for this tag

But I'm not sure what else it'd use here unless it used a raw byte, but I can't even find that

see comments on line 177 in tx_extra.h

... oh. Is it just always at the end of TX extra?

padding should be at the end

Right, which was the comment to the contrary

And I do know the sort order. I just find it weird if PADDING is interpreted as read to end

But that explains the eof break check :p

I assumed that was operating on a subslice, not on the extra vector itself

So padding is read to end and doesn't have its own defined length. Monero only properly supports 254 bytes of arb data

Right?

And thank you :)

padding must be all 0's

you shouldn't put arbitrary data there

... wait what? What field am I thinking of then?

tx_extra_nonce can be anything

up to 255 bytes (not including varint length)

Why does Monero have a field for null data?

I'm not even sure the theoretical value of that .-.

That does make much more sense though (as it's just a size_t). I thought this was just ignoring the arbitrary data because it didn't care.

Really not familiar with the macros here.

I don't think padding is even used anywhere

technically, you can put any unused tag in extra field and write any data there, not limited to 255 bytes

just keep the format (1 byte for tag, then varint length, then data of that length)

Thanks. Planning to just use a second Nonce field.

actually, if you add new tag value, parse_tx_extra will fail which can create problems for tx recipient

unless the code on receiving side is also updated

That was my concern :p I'm not planning such TXs (to wallet2 with arb data), but I believe a secondary nonce would be fine so long as its second in the ordering. Else, I'll reuse minergate lol.

you can use multiple tx_extra_nonce tags

yeah tx_extra is limited by block size iirc

only first tx_extra_nonce is used for something, if I read the code right

theres been a few massive ones in the past

tx_extra is not limited, but the whole tx size is limited

correct

oh separate from block size?

tx size limit is derived from median block size

max size that can be mined or added to mempool is 1/2 of mediab block size

wallet2 limits it even further to 1/3 but it's not consensus

I've removed this limitation from wallet2 and created bigger transactions that were mined

there's also #define CRYPTONOTE_MAX_TX_SIZE 1000000

but we're far from that limit yet

Is this a good place to ask for help about setting up a xmr exclusive btcpay server?

Not too likely. You can look for a btcpay channel. If there's none, maybe #monero-community might have someone who knows about this.

Ok, thanks

plowsof: This is exactly the guide I'm using but it's mentioning some non existent variables plus other things, I think it may be outdated. I'm trying to contact Seth but he didn't answered me yet.