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?

I'm looking at a use-case where the SENDER would generate the pid and include it in the transaction

sgp_: here is some python code that'll do that: paste.debian.net/plainh/46f1c459

tobtoht: does what does `secrets.token_hex(8)`do specifically?

sgp_: generates a random 8 byte hex string like "6ce1e744b9e2bad8"

what if I wanted to provide my string which was already generated?

PaymentID() takes a string up to a certain character limit

so you could do

my_pid = "payment_id_here"

PaymentID(my_pid)

perfect

how does the encryption of this short pid work?

I assume it's decrypted with the private view key, but also I'm not 100% sure on that either

also what does it mean in xmrchain when it says "Payment id (encrypted): e074da1078f11738" xmrchain.net/tx/67831f68dc26c006353…3c82d1b59dd91fe9a67707968076cc2387d

is e074da1078f11738 not the normal decrypted pid?

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

so if I was the recipient of 67831f68dc26c006353f5a8441f703c82d1b59dd91fe9a67707968076cc2387d, I would see a different pid other than e074da1078f11738? But which is the same length?

so encrypted pids are staying?

sgp_: yes, payment ids in integrated addresses are always 64 bits / 8 bytes long

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

tobtoht: thank you, this is very helpful

wtf is thorchain doing thats worth leaving screen doors on our submarine

no KYC "DEX" swaps, synthetic XMR assets on other chains like ETH, etc

personally I buy the use-case as "reasonable enough"

others may disagree obviously

i guess. seems to be all the rage. i still think being money is sorta the primary important thing ...

can't they do what they need within the bp+ thinger?

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)

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

well ...... maybe we should just switch to bp+ before they go all out building stuff that we'll hope to deprecate within n years?

i mean yeah sgp_ , thats awesome

their timeline is <3 mo

if BP+ encrypted messaging can be added before then, they will probably adopt it I think, if not, encrypted pid

well i guess as long as they understand that at some point monero may force them to change their whole thing, then cool

luckily it wouldn't be the "whole thing" for moving from a pid message to a BP+ message

assuming that the BP+ message is decrypted by the private view key

but man oh man, this kinda stuff is indicative that these holes have to be plugged

also how many months is heart months? <3

I completely agree that the totally wild west tx_extra should be addressed

BP can do data embedding too

yeah, i thought it wasn't unique to BP+

decrypted with the private view key, just to be 100% sure?

^ for both encrypted pid and BP/BP+

sgp_: for payment ids see page 42 ZtoM2. The private view key and tx public key are required to decrypt the pid.

For data embedding you can use whatever construction you want

Presumably using the shared sender-recipient secret

It's a general construction

Note that it's 64 bytes per proof, not per recipient/output

And a transaction has a single proof

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.

64 bytes, not 32 ?

And I can add code to pass user data in BP+, that's something I wanted to look at at some point anyway.

This is also a good time to discuss "do we want a flat encrypted <insert number> byte data in every tx" again.

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).

here is the spec that is being considered for Thorchain gitlab.com/thorchain/thornode/-/issues/919

they will take a sha256 hash of a command added to their blockchain and use the first 16 characters

they want that to be passed along with a monero transaction

That'd fit snug in a BP+ extra data.

sure, if the CLI wallet clearly showed that, then they would probably be super open to using that field instead

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

It doesn't exist yet, but I'm willing to add tooling for it.

It does not increase size.

We are using the space, but we can still fit something in.

oh excellent, so we can pass this along for free. that's great news

is it a huge amount of work to add the tooling?

Not huge. Not trivial. Medium maybe. For some handwavy definition of medium.

Low-medium.

At first approximation anyway.

Though if they're fine with 16 characters, assuming it's 16 hex chars, that one fits in the short payment id.

they need 16 characters to match against the first 16 characters of a sha256 hash

That is however probably shit since I assume the full string will be public, so it becomes trivial to map it back.

so my impression is that fits in an encrypted payment ID

However, if thay payment id is encrypted, then it's OK I think.

they need a monero transaction to pass along a string that looks like this: 2aab7b9a80d9d65f

Depends whether only the recipient needs to decode it, or whether it needs to be publicly known.

The later case -> bad user

latter

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

sha256 hashes are all hex right?

They can be printed out as hex, like any other data.

I guess we need to discuss whether we want to prevent that before they start doing it.

Or maybe it's just some "use this at your own risk".

how would you prevent it? even if you yank out tx_extra, they could use the BP message

Yes, but the harder it is to use, the less likely it us to be used :)

Would those public wallets' key images be publicly known ?

if anything it's a reason to bump the ringsize I think in anticipation

yup key images known too 😬

Fuckers...

what needs to happen on a dev side before the next protocol update?

Merge BP+, I think it's not yet.

Possibly review/merge triptych if we want it in too.

But triptych would be best with shiny bins for rings, which we do not have yet.

And noone doing this AFAIK.

Oh, and no multisig yet anyway.

So no triptych.

ArticMine's fee changes.

Inge-: Triptych uses a weighted key aggregation, but not in the same way as Arcturus

That being said, it should still be noted that Triptych hasn't undergone a formal audit either

And this is a good opportunity to review the aggregation used in Triptych

right. But Monero does reviews before implementing. Did Turtlecoin or someone put Arcturus into production?

AFAIK TurtleCoin had code and was planning a deployment

Arcturus preprint has been withdrawn: eprint.iacr.org/2020/312

So BP+, fee changes, BP+ 32 byte storage, ringsize bump?

tx_extra phaseout?

and this might be more for dev

Sure let's move there

phaseout sounds untenable

since tx_extra is apparently essential to mining

but it is encrypted, no? So it is not a privacy issue, more a tx size issue?

<sarang "Arcturus preprint has been withd"> ErCiccione: maybe you should include a note about this on the MRL page getmonero.org/resources/research-lab

endor00: thanks for the ping. Will do.

Good call endor00[m], thanks for noting this

The existing IACR link will continue to work indefinitely (they keep old versions for a historical record)

but the "current version PDF" link will not exist (you need to view previous versions to get the PDF)

sarang: As a side note, have you already started delving into the multisig research for Triptych?

Slowly but surely!

what are the statistics on using a random 193 in tx from the chain? xmrchain.net/tx/c50abc8199c40c7bfd1…03fdc81a74787ac7d72929bbf9d77c9d702