00:18:16 <sgp_> Is there any tool to take a Monero base address (4...) and add a 16 digit payment ID to it to make it an integrated address?
00:18:51 <sgp_> I'm looking at a use-case where the SENDER would generate the pid and include it in the transaction
00:38:13 <tobtoht> sgp_: here is some python code that'll do that: http://paste.debian.net/plainh/46f1c459
00:41:03 <sgp_> tobtoht: does what does `secrets.token_hex(8)`do specifically?
00:41:55 <tobtoht> sgp_: generates a random 8 byte hex string like "6ce1e744b9e2bad8"
00:42:43 <sgp_> what if I wanted to provide my string which was already generated?
00:44:03 <tobtoht> PaymentID() takes a string up to a certain character limit
00:44:36 <tobtoht> so you could do
00:44:41 <tobtoht> my_pid = "payment_id_here"
00:44:46 <tobtoht> PaymentID(my_pid)
00:45:03 <sgp_> perfect
00:47:34 <sgp_> how does the encryption of this short pid work?
00:48:06 <sgp_> I assume it's decrypted with the private view key, but also I'm not 100% sure on that either
00:52:25 <sgp_> also what does it mean in xmrchain when it says "Payment id (encrypted): e074da1078f11738" https://xmrchain.net/tx/67831f68dc26c006353f5a8441f703c82d1b59dd91fe9a67707968076cc2387d
00:56:06 <sgp_> is e074da1078f11738 not the normal decrypted pid?
01:03:38 <tobtoht> sgp_: if I am not mistaken the payment id embedded unencrypted in the address, but is encrypted with the public view key on the blockchain
01:05:49 <sgp_> so if I was the recipient of 67831f68dc26c006353f5a8441f703c82d1b59dd91fe9a67707968076cc2387d, I would see a different pid other than e074da1078f11738? But which is the same length?
01:08:09 <gingeropolous> so encrypted pids are staying?
01:09:06 <tobtoht> sgp_: yes, payment ids in integrated addresses are always 64 bits / 8 bytes long
01:09:31 <sgp_> gingeropolous: honestly that's a super good question, and if Thorchain can integrate using only encrypted pids, I think I'll change my mind and support its inclusion
01:09:39 <sgp_> tobtoht: thank you, this is very helpful
01:10:31 <gingeropolous> wtf is thorchain doing thats worth leaving screen doors on our submarine
01:11:48 <sgp_> no KYC "DEX" swaps, synthetic XMR assets on other chains like ETH, etc
01:12:04 <sgp_> personally I buy the use-case as "reasonable enough"
01:12:38 <sgp_> others may disagree obviously
01:12:50 <gingeropolous> i guess. seems to be all the rage. i still think being money is sorta the primary important thing ...
01:13:07 <gingeropolous> can't they do what they need within the bp+ thinger?
01:13:54 <sgp_> they most likely can when that's built out, sure. And when built, I would recommend switching to that (which they would probably be open to do)
01:14:47 <sgp_> in <24 hours I've talked them down from adding 190 unique, unencrypted bytes in tx_extra to using the encrypted, standard-format pid. There's room to work within the lines of reason I think
01:15:10 <gingeropolous> well ...... maybe we should just switch to bp+ before they go all out building stuff that we'll hope to deprecate within n years?
01:15:19 <gingeropolous> i mean yeah sgp_ , thats awesome
01:15:25 <sgp_> their timeline is <3 mo
01:16:07 <sgp_> if BP+ encrypted messaging can be added before then, they will probably adopt it I think, if not, encrypted pid
01:16:50 <gingeropolous> well i guess as long as they understand that at some point monero may force them to change their whole thing, then cool
01:17:22 <sgp_> luckily it wouldn't be the "whole thing" for moving from a pid message to a BP+ message
01:17:40 <sgp_> assuming that the BP+ message is decrypted by the private view key
01:17:41 <gingeropolous> but man oh man, this kinda stuff is indicative that these holes have to be plugged
01:19:52 <gingeropolous> also how many months is heart months?  <3
01:20:00 <sgp_> I completely agree that the totally wild west tx_extra should be addressed
01:20:09 <sarang> BP can do data embedding too
01:20:22 <gingeropolous> yeah, i thought it wasn't unique to BP+
01:20:26 <sgp_> decrypted with the private view key, just to be 100% sure?
01:21:42 <sgp_> ^ for both encrypted pid and BP/BP+
01:27:21 <tobtoht> sgp_: for payment ids see page 42 ZtoM2. The private view key and tx public key are required to decrypt the pid.
01:32:04 <sarang> For data embedding you can use whatever construction you want
01:32:26 <sarang> Presumably using the shared sender-recipient secret
01:32:43 <sarang> It's a general construction
01:35:23 <sarang> Note that it's 64 bytes per proof, not per recipient/output
01:35:28 <sarang> And a transaction has a single proof
06:54:24 <Inge-> sarang: I presume Triptych is not using unproven soundness assumptions? Arcturus is an excellent learning example of why making such assumptions is irresponsible when much is at stake.
06:55:03 <moneromooo> 64 bytes, not 32 ?
06:55:45 <moneromooo> And I can add code to pass user data in BP+, that's something I wanted to look at at some point anyway.
06:56:21 <moneromooo> This is also a good time to discuss "do we want a flat encrypted <insert number> byte data in every tx" again.
06:57:00 <moneromooo> I have a patch for that on github, and it got kinda lost in discussion of the number (which was a function in my case).
13:26:05 <sgp_> here is the spec that is being considered for Thorchain https://gitlab.com/thorchain/thornode/-/issues/919
13:26:32 <sgp_> they will take a sha256 hash of a command added to their blockchain and use the first 16 characters
13:26:48 <sgp_> they want that to be passed along with a monero transaction
13:27:14 <moneromooo> That'd fit snug in a BP+ extra data.
13:28:26 <sgp_> sure, if the CLI wallet clearly showed that, then they would probably be super open to using that field instead
13:29:40 <sgp_> does using the BP+ extra data increase the size of all transactions that use the field by 32 bytes? Or is this free space we aren't using right now
13:30:18 <moneromooo> It doesn't exist yet, but I'm willing to add tooling for it.
13:30:26 <moneromooo> It does not increase size.
13:30:38 <moneromooo> We are using the space, but we can still fit something in.
13:30:49 * moneromooo tries to think of an analogy
13:30:54 <sgp_> oh excellent, so we can pass this along for free. that's great news
13:31:55 <sgp_> is it a huge amount of work to add the tooling?
13:32:52 <moneromooo> Not huge. Not trivial. Medium maybe. For some handwavy definition of medium.
13:33:09 <moneromooo> Low-medium.
13:33:21 <moneromooo> At first approximation anyway.
13:34:15 <moneromooo> Though if they're fine with 16 characters, assuming it's 16 hex chars, that one fits in the short payment id.
13:34:53 <sgp_> they need 16 characters to match against the first 16 characters of a sha256 hash
13:34:55 <moneromooo> That is however probably shit since I assume the full string will be public, so it becomes trivial to map it back.
13:35:03 <sgp_> so my impression is that fits in an encrypted payment ID
13:35:35 <moneromooo> However, if thay payment id is encrypted, then it's OK I think.
13:36:57 <sgp_> they need a monero transaction to pass along a string that looks like this: 2aab7b9a80d9d65f
13:37:45 <moneromooo> Depends whether only the recipient needs to decode it, or whether it needs to be publicly known.
13:37:45 <moneromooo> The later case -> bad user
13:37:45 <moneromooo> latter
13:40:40 <sgp_> it doesn't need to be publicly known on the monero chain, but it will be made public since the receiving wallet view key is public
13:41:24 <sgp_> sha256 hashes are all hex right?
13:41:46 <moneromooo> They can be printed out as hex, like any other data.
13:42:35 <moneromooo> I guess we need to discuss whether we want to prevent that before they start doing it.
13:42:54 <moneromooo> Or maybe it's just some "use this at your own risk".
13:45:52 <sgp_> how would you prevent it? even if you yank out tx_extra, they could use the BP message
13:46:22 <moneromooo> Yes, but the harder it is to use, the less likely it us to be used :)
13:47:18 <moneromooo> Would those public wallets' key images be publicly known ?
13:47:19 <sgp_> if anything it's a reason to bump the ringsize I think in anticipation
13:47:30 <sgp_> yup key images known too 😬
13:47:34 <moneromooo> Fuckers...
13:49:30 <sgp_> what needs to happen on a dev side before the next protocol update?
14:02:04 <moneromooo> Merge BP+, I think it's not yet.
14:02:23 <moneromooo> Possibly review/merge triptych if we want it in too.
14:02:53 <moneromooo> But triptych would be best with shiny bins for rings, which we do not have yet.
14:03:10 <moneromooo> And noone doing this AFAIK.
14:03:28 <moneromooo> Oh, and no multisig yet anyway.
14:03:34 <moneromooo> So no triptych.
14:03:52 <moneromooo> ArticMine's fee changes.
14:03:57 <sarang> Inge-: Triptych uses a weighted key aggregation, but not in the same way as Arcturus
14:04:12 <sarang> That being said, it should still be noted that Triptych hasn't undergone a formal audit either
14:04:28 <sarang> And this is a good opportunity to review the aggregation used in Triptych
14:05:03 <Inge-> right. But Monero does reviews before implementing. Did Turtlecoin or someone put Arcturus into production?
14:05:28 <sarang> AFAIK TurtleCoin had code and was planning a deployment
14:21:28 <sarang> Arcturus preprint has been withdrawn: https://eprint.iacr.org/2020/312
14:30:16 <sgp_> So BP+, fee changes, BP+ 32 byte storage, ringsize bump?
14:31:48 <gingeropolous> tx_extra phaseout?
14:32:15 <gingeropolous> and this might be more for dev
14:32:27 <sgp_> Sure let's move there
14:32:36 <hyc> phaseout sounds untenable
14:32:55 <hyc> since tx_extra is apparently essential to mining
14:34:51 <Inge-> but it is encrypted, no? So it is not a privacy issue, more a tx size issue?
14:50:10 <endor00[m]> <sarang "Arcturus preprint has been withd"> ErCiccione: maybe you should include a note about this on the MRL page https://www.getmonero.org/resources/research-lab/
14:51:30 <ErCiccione> endor00: thanks for the ping. Will do.
14:53:10 <sarang> Good call endor00[m], thanks for noting this
14:53:33 <sarang> The existing IACR link will continue to work indefinitely (they keep old versions for a historical record)
14:53:52 <sarang> but the "current version PDF" link will not exist (you need to view previous versions to get the PDF)
15:10:12 <dEBRUYNE> sarang: As a side note, have you already started delving into the multisig research for Triptych?
15:17:37 <sarang> Slowly but surely!
19:22:39 <gingeropolous> what are the statistics on using a random 193 in tx from the chain? https://xmrchain.net/tx/c50abc8199c40c7bfd174cf67fc2403fdc81a74787ac7d72929bbf9d77c9d702