03:33:25 <kayabaNerve> We only ban torsion on key images, right? Everything else doesn't care?
03:33:48 <kayabaNerve> 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.
03:33:55 <kayabaNerve> *also asking about the protocol and wallet2
03:37:20 <UkoeHB> Yes
03:47:15 <kayabaNerve> 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]
03:47:33 <kayabaNerve> *< l
03:55:51 <UkoeHB> afaik point deserialization is not checked
04:05:11 <kayabaNerve> Uhhhhh it is the second it passes through consensus.
04:05:28 <kayabaNerve> So you're right in that the output key is treated as a byte array despite being rct::key
04:05:45 <kayabaNerve> Yet any rct::key we do operate with as a point...
04:06:14 <kayabaNerve> 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].
04:06:26 <kayabaNerve> ... right?
04:07:01 <kayabaNerve> 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 ;)
04:08:40 <kayabaNerve> 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.
04:56:13 <UkoeHB> onetime addresses and ephemeral pubkeys are not deserialized during verification
04:56:22 <UkoeHB> for new outputs
04:56:36 <UkoeHB> unless I'm mistaken
04:57:38 <kayabaNerve> Seems like it from my double checks (as ephemeral keys aren't even acked by consensus).. Thanks for confirming :)
18:01:54 <wale2> 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?
18:09:05 <moneromooo> Instead of giving your address for payment, give Carol's address instead. Ask Carol, who should be trusted by both you and your counterparties.
18:09:20 <moneromooo> I don't think you need to code anything for that really.
18:09:49 <moneromooo> Well, not monero code anyway.
18:15:30 <wale2> Not sure if I understand. Is Carol on the Seller side?
18:22:03 <one-horse-wagon[> 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. 
18:30:00 <moneromooo> Carol is the escrow.
18:30:57 <wale2> 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
18:31:51 <moneromooo> 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...
18:32:13 <moneromooo> The whole *point* of an escrow is that it's independent.
18:32:42 <moneromooo> It's a social thing, not a code thing.
18:34:09 <wale2> 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
19:05:31 <kayabaNerve> 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.
19:09:15 <sech1> what? It loops from 1 to 255 and reads 1 byte per iteration
19:09:24 <sech1> so 255 bytes
19:10:22 <sech1> hmm, actually it can only store 254 bytes
19:10:28 <sech1> store and load functions are inconsistent
19:11:21 <kayabaNerve> ... fun
19:11:36 <kayabaNerve> So I'm not sure what's up there, I just wanted to confirm that if I didn't want to cause Monero
19:12:00 <kayabaNerve> *Monero's pareser to error, I should limit my lib's data field to 254 bytes
19:12:36 <kayabaNerve> Oh. 1 .. <= 255 is 255 bytes, right.
19:13:45 <kayabaNerve> Except on writing 255, yeah, it becomes 256 and serialize errors.
19:13:49 <sech1> looking at comments there, it's 255 bytes including variant tag
19:13:56 <sech1> so variant tag + up to 254 zeros
19:14:07 <kayabaNerve> But not the varint len, and the data itself is 254
19:14:16 <kayabaNerve> ... this does have a varint len after the tag, right?
19:14:29 <kayabaNerve> I was pretty sure so, and have always used that assumption, but there's a comment to the contrary
19:14:42 <sech1> there's no varint len for this tag
19:14:44 <kayabaNerve> But I'm not sure what else it'd use here unless it used a raw byte, but I can't even find that
19:14:56 <sech1> see comments on line 177 in tx_extra.h
19:14:58 <kayabaNerve> ... oh. Is it just always at the end of TX extra?
19:15:11 <sech1> padding should be at the end
19:15:13 <kayabaNerve> Right, which was the comment to the contrary
19:15:25 <kayabaNerve> And I do know the sort order. I just find it weird if PADDING is interpreted as read to end
19:15:31 <kayabaNerve> But that explains the eof break check :p
19:15:44 <kayabaNerve> I assumed that was operating on a subslice, not on the extra vector itself
19:16:16 <kayabaNerve> So padding is read to end and doesn't have its own defined length. Monero only properly supports 254 bytes of arb data
19:16:18 <kayabaNerve> Right?
19:16:21 <kayabaNerve> And thank you :)
19:16:52 <sech1> padding must be all 0's
19:17:00 <sech1> you shouldn't put arbitrary data there
19:17:25 <kayabaNerve> ... wait what? What field am I thinking of then?
19:17:38 <sech1> tx_extra_nonce can be anything
19:17:55 <sech1> up to 255 bytes (not including varint length)
19:18:03 <kayabaNerve> Why does Monero have a field for null data?
19:18:34 <kayabaNerve> I'm not even sure the theoretical value of that .-.
19:19:12 <kayabaNerve> 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.
19:19:17 <kayabaNerve> Really not familiar with the macros here.
19:20:06 <sech1> I don't think padding is even used anywhere
19:25:28 <sech1> technically, you can put any unused tag in extra field and write any data there, not limited to 255 bytes
19:25:44 <sech1> just keep the format (1 byte for tag, then varint length, then data of that length)
19:29:45 <kayabaNerve> Thanks. Planning to just use a second Nonce field.
19:36:28 <sech1> actually, if you add new tag value, parse_tx_extra will fail which can create problems for tx recipient
19:36:49 <sech1> unless the code on receiving side is also updated
19:43:30 <kayabaNerve> 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.
19:45:15 <sech1> you can use multiple tx_extra_nonce tags
19:47:46 <vtnerd> yeah tx_extra is limited by block size iirc
19:47:49 <sech1> only first tx_extra_nonce is used for something, if I read the code right
19:48:16 <vtnerd> theres been a few massive ones in the past
19:48:23 <sech1> tx_extra is not limited, but the whole tx size is limited
19:48:38 <vtnerd> correct
19:48:53 <vtnerd> oh separate from block size?
19:49:10 <sech1> tx size limit is derived from median block size
19:49:30 <sech1> max size that can be mined or added to mempool is 1/2 of mediab block size
19:49:48 <sech1> wallet2 limits it even further to 1/3 but it's not consensus
19:50:06 <sech1> I've removed this limitation from wallet2 and created bigger transactions that were mined
19:54:08 <sech1> there's also #define CRYPTONOTE_MAX_TX_SIZE 1000000
19:54:15 <sech1> but we're far from that limit yet
20:45:14 <rub-ick[m]> Is this a good place to ask for help about setting up a xmr exclusive btcpay server? 
20:47:09 <moneromooo> Not too likely. You can look for a btcpay channel. If there's none, maybe #monero-community might have someone who knows about this.
20:57:55 <rub-ick[m]> Ok, thanks
21:04:42 <rub-ick[m]> 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.