xmrchain node, (v0.17.0.0-83f35d5db), uptime 34d 21h 12m 26s . gonna build current master and run that now

huh, the hash id when u start monero didn't change. ah well.

Hi all, just FYI I've set up a bounty for that decoy selection bug: bounties.monero.social/posts/33/fix…selection-bug-monero-gui-issue-3733

@selsta in particular

I'm getting an error compiling against monero-project master that I don't get on the v0.17 branch:... (full message at libera.ems.host/_matrix/media/r0/do…09b54f51cff390488cf4624d41e30fe5fa5)

the error is caused by calling ps.store_to_binary(bin) with a string (this signature changed from `store_to_binary(binarybuffer& target)` in v0.17 to `store_to_binary(byte_stream& ss)` in master so understandable)

but then levin_abstract_invoke2.h still calls `store_to_binary()` with a string and compiles

so two questions: how can I use the updated method to write to a string? how is levin_abstract_invoke2.h compiling?

github.com/monero-ecosystem/monero-…est/TestMoneroWalletCommon.js#L2270 woodser I was a bit confused about creating a payment uri with an integrated address. So I started reading the tests. It seems that this api is expecting a 65 character string as payment_id. I am assuming this will produce an integrated address under the hood, true? On the other hand I saw the docs

on the monero wallet rpc which expects a 16 char hex string to make an integrated_address: getmonero.org/resources/developer-g…et-rpc.html#make_integrated_address I am bit confused by this. Ideally I would like to use the make_uri api and also generated an integrated address under the hood and get handed back the randomly generated 16 char payment id.

s/generated/generate/

I also tried to dig deeper into the code. Am I right that monero-javascript is interacting with the wallet2.cpp file in the monero project? So the code in question is this: github.com/monero-project/monero/bl…6179d/src/wallet/wallet2.cpp#L13732

Also by the way: in the monero wallet rpc docs I see both 16 bit and 64 bit as an example for making an integrated address (in the introduction at the top its 64 and then below its 16) getmonero.org/resources/developer-g…et-rpc.html#make_integrated_address Which is the right one, 16 or 64 or can I use both?

you can first create the integrated address and retrieve the randomly generated payment id:... (full message at libera.ems.host/_matrix/media/r0/do…5cef620f5e518b6237f44e2a64a32777c22)

then from that you can create a payment uri with the integrated address:

`let paymentUri = await wallet.createPaymentUri(new MoneroTxConfig().setAddress(integratedAddress.getIntegratedAddress()).setAmount(new BigInteger("425000000000"))`

which yields this payment uri: `{"destinations":[{"address":"5DtiRu1pUvKdnw7NPafr5ZdCRj1Qa4SYN56cgfozAwCeMj7TZazWe1bip8A5UCPKK7RrpGaP97vsxHabwYEWUCWQgpn7GkAGGnRMhAH4ow","amount":425000000000}]}`

er, actually this would be the payment uri: monero:5DtiRu1pUvKdnw7NPafr5ZdCRj1Qa4SYN56cgfozAwCeMj7TZazWe1bip8A5UCPKK7RrpGaP97vsxHabwYEWUCWQgpn7GkAGGnRMhAH4ow?tx_amount=0.425000000000

confusingly, you can give the payment id to `make_uri` separately, and it creates a payment uri with the payment id separate: monero:54C3R6CKseodnw7NPafr5ZdCRj1Qa4SYN56cgfozAwCeMj7TZazWe1bip8A5UCPKK7RrpGaP97vsxHabwYEWUCWQTspBZGZ?tx_payment_id=03284e41c342f03603284e41c342f03603284e41c342f03603284e41c342f036&tx_amount=0.425000000000

and `make_uri` only allows 64 character payment ids though

I was thinking only 64 character payment ids are allowed now

also note integrated addresses are discouraged over subaddresses nowadays

thanks a lot! I am still a bit confused over which size is the right one for the payment_id. So I will just use getIntgeratedAddress and hope it generates an "officially sized" payment_id. Is it expensive (computationally) to create this MoneroWalletFull object? I would want to create integrated address for many different wallets that I dont have the private keys to. I want to create a non custodial marketplace that technically does not

even have its own wallet. I would just use the addresses of the prospective sellers and make integrated addresses with them and then ask the prospective buyers to supply payment proof.

<woodser[m]> "also note integrated addresses..." <- I know some discourage it, but I see no other choice. If I let the buyer pick and choose which transaction payed for a product I open myself up to race conditions and a lot more complexity in the backend. For example I ask the buyer to pay 1 xmr for a product and submit payment proof. Now he quickly buys the same product twice and submits the proof to both buy requests he made to the

server.

<spirobel[m]> "I also tried to dig deeper..." <- yes monero-javascript interacts with wallet2 when using `MoneroWalletFull` instead of `MoneroWalletRpc` which is just a client of monero-wallet-rpc

it's definitely confusing to me that `make_integrated_address` returns a 16 character hex when I think 64 characters required now. anyone know what's up with this?

creating the MoneroWalletFull object is a matter of downloading and initializing a 5.24 mb wasm file. shouldn't be prohibitively expensive

woodser[m]: oh thats not good. Seems like I need to write a function by hand to make integrated addresses from normal addresses

ah yes that's expensive if every client downloads it as part of a web app

Its running server side

ah then the file size shouldn't matter?

hm...I dont know about wasm. It just scared me for a second. That maybe its an expensive operation to "open a wallet" because I have the feel for opening monero-gui on my desktop computer

and I might generate huge amounts of integrated addresses in short order. Its just adding a random number to a string, right?

so if it means I have to reload 5.24 mb into the server memory again and again it might be better to write a small js function that adds the random number to the wallet address and recalculates the checksum

but maybe I am thinking too far

I see. you need a utility that creates an integrated address when you only have a wallet's address. the utility I pointed you to is for a wallet you have the keys to, so a new standalone utility is needed.

either way the server should just load the file once on startup and use it whenever a new integrated address is needed, so the cost should be negligible

<spirobel[m]> "I know some discourage it, but I..." <- ideally you would prompt the seller to give you a new subaddress for a specific sale, and then the buyer can provide proof of payment to that subaddress

feel free to open an issue for the library to support creating integrated addresses as a standalone utility and we can add support for it

woodser[m]: this is not good. It makes everything so much more complex. If I am not mistaken the (async) checkTxProof(txHash, address, message, signature) → {MoneroCheckTx} function allows me to check tx proofs for destination addresses that are not the wallet itself, right? So I would just need to have a utility to make the integrated addresses, right?

It would still be a bit awkward to build this kind of thing because there is this wallet lying around on a server that does not even need a wallet because the service is non custodial

but it least it would be possible

s/it/at/

yeah it's a little awkward creating a wallet just to use utility methods like `checkTxProof()`. guess it would be better served through the daemon

yes `checkTxKey()` and `checkTxProof()` lets you verify payments to external wallets

woodser[m]: amazing I also thought about this again. I can use github.com/monero-ecosystem/monero-…est/TestMoneroWalletCommon.js#L2262 makepaymenturi and supply a MoneroTxConfig with the address of the seller I guess it also does not need to be the wallet address. And then I just randomly generate 64 bits and supply it. Guess its less effort for now. But ultimately

these utility functions should be separated from the wallet. It would help unfuck my brain haha

<spirobel[m]> "this is not good. It makes..." <- I also thought about this more. Subaddresses wouldnt be possible in this situation because the sellers of this non custodial market place should not be only all the time. So they would either have to supply their viewkey (which i dont want....kinda defeats the purpose of monero.. and its also really really really nasty to implement because I would need to open lots of wallets instead of

just using some utility functions)

s/only/online/

Thanks a lot for you help! Its fun exploring this together haha!

👍️

spirobel[m]: yeah this should work

s/only/online/, s/either//

it should be possible to derive receiving addresses from a view-key without scanning and this could also be incorporated into the library

happy to help, feel free to DM

I don't understand why you took the logn road spirobel . You don't want sellers to trust you with the view keys which is fine but they do trust you will show their address to the buyer? Why don't you just associate a monero account with each seller on your website and each item an associated subaddress? Then you just monitor the transactions to prove that the buyer bought instead of requiring them to send a proof. Then on the server

side, upon 10 confirmations or whatever, the monero will be auto sent to the address the seller provided.

s/logn/long/

s/logn/long/, s/Then/On/, s/on//

s/I don't understand why you took the logn road spirobel . You don't want sellers to trust you with the view keys which is fine but they do trust you will show their address to the buyer? Why don't you just associate a monero account with each seller on your website and each item an associated subaddress? Then you just monitor the transactions to prove that the buyer bought instead of requiring them to send a proof. Then on the server

side, upon 10 confirmations or whatever, the monero will be auto sent to the address the seller provided./I don't understand why you took the long road spirobel . You don't want sellers to trust you with the view keys which is fine but they do trust you will show their address to the buyer? Why don't you just associate a monero account with each seller on your website and each item an associated subaddress? Then you just monitor the

transactions to prove that the buyer bought instead of requiring them to send a proof. On the server side, upon 10 confirmations or whatever, the monero should be auto sent to the address the seller provided. /

s/I don't understand why you took the logn road spirobel . You don't want sellers to trust you with the view keys which is fine but they do trust you will show their address to the buyer? Why don't you just associate a monero account with each seller on your website and each item an associated subaddress? Then you just monitor the transactions to prove that the buyer bought instead of requiring them to send a proof. Then on the server

side, upon 10 confirmations or whatever, the monero will be auto sent to the address the seller provided./I don't understand why you took the long road spirobel. You don't want sellers to trust you with the view keys which is fine but they do trust you will show their address to the buyer? Why don't you just associate a monero account with each seller on your website and each item an associated subaddress? Then you just monitor the

transactions to prove that the buyer bought instead of requiring them to send a proof. On the server side, upon 10 confirmations or whatever, the monero should be auto sent to the address the seller provided. /

s/I don't understand why you took the logn road spirobel . You don't want sellers to trust you with the view keys which is fine but they do trust you will show their address to the buyer? Why don't you just associate a monero account with each seller on your website and each item an associated subaddress? Then you just monitor the transactions to prove that the buyer bought instead of requiring them to send a proof. Then on the server

side, upon 10 confirmations or whatever, the monero will be auto sent to the address the seller provided./I don't understand why you took the long road spirobel. You don't want sellers to trust you with the view keys which is fine but they do trust you will show their address to the buyer? Why don't you just associate a monero account with each seller on your website and each item an associated subaddress? Then you just monitor the

transactions to confirm that the buyer bought instead of requiring them to send a proof. On the server side, upon 10 confirmations or whatever, the monero should be auto sent to the address the seller provided. /

Elijah[m]1, please don't edit things in matrix. it floods the IRC side with the same message. Also, this is better suited for #monero

woodser, regarding: "it's definitely confusing to me that `make_integrated_address` returns a 16 character hex when I think 64 characters required now. anyone know what's up with this?"

I think you got that exactly backwards: Only "short payment ids" (16) are supported, the "long payment ids" (64) are gone

<Elijah[m]1> "I don't understand why you..." <- its non custodial. there is no monero sent on the server. Your idea wouldnt work, because the race condition is still there, just per product This race condition gets even worse when you consider pricing in usd and fluctuating price.

What's the race condition?

Elijah[m]1: buy product multiple times and supply the same transaction proof multiple times.

(for the same transaction)

it will make the implementation a lot more complex

Well if you want to allow multiple purchases for each product, each ORDER should have an associated subaddress

Elijah[m]1: yes. this is how it would need to be done. On top of that I would need to figure out how to use monero-javascript with a boatload of wallets.

What's wrong with the wallet-rpc?

it needs to be easy to deploy. I went this route before. integrating monero wallet rpc with discourse. but it is way to cumbersome to have this daemon running when all i need is a basic library function. On top of it because the backend is ruby and there is no monero rpc client for ruby i can make my rpc calls by hand. Honestly i just want to get this done. quickly. and easy to deploy as one javascript blob. So thats why I am going with

monero-javascript and makepaymenturi and 64 bit random payment id

maybe subaddresses should be deprecated instead of integrated addresses. If we had libraries that didnt depend on a wallet the developer UX would be soo much better than subaddresses. We could easily build non custodial services. Think of the possibilities

Bad take

In the short-term prioritizing throughput/productivity is okay, but in the long-term user UX should be a priority.

Requiring the user to do more than just sending Monero is bad UX

But if the priority is subjective (namely get it out ASAP)

Elijah[m]1: yeah and the ux of integrated addresses is better. if we had a browser wallet this whole thing would be one click. and you could supply the transaction proof as a return

think about eth3.js

we need to make xmr3.js

you also need to think about developer ux. there is no way to build what i want to build with subaddresses at the moment.

nobody thought of handling large amount of viewkeys on a server

and make it non cumbersome

I don't know shit about fuck but pretty sure MyMonero handles loads of viewkeys server side you could see what they do

<rbrunner> "woodser, regarding: "it's..." <- if that's true, then this must be a bug, where `make_uri` enforces a long payment id and rejects the short ones: github.com/monero-project/monero/bl…6179d/src/wallet/wallet2.cpp#L13732

spirobel you said in the UX channel that you don't want to get the vieww guys from the sellers.

Lyza: okay good point. but I dont want to waste even more time. I just want to get it done. I also bet it isnt documented very well.

s/spirobel you said in the UX channel that you don't want to get the vieww guys from the sellers./spirobel you said in the UX channel that you don't want to get the view keys guys from the sellers./

Elijah[m]1: yes. because its not necessary

s/vieww/view/, s/guys/keys/

so why are you using it as an argument?

so you just want an web3.xmr then?

spirobel[m] haven't you seen monero-lws?

man is there a UX channel for monero on IRC?

oh

nice

you could have the seller give you a bunch of subaddresses upfront, enough to cover e.g. 100 orders, and request more if ever needed

then have the buyers prove payments to those subaddresses

wooders: Yeah, that looks like a bug. I just saw now the code in 'simplewallet' that forbids long payment ids now, it's really only the short ones that survived

<Elijah[m]1> "so why are you using it as an..." <- Just think about what I want to make and you will come to the same conclusions. In the beginning I also wanted to get the viewkeys, but it just does not work like that. To handle alone the scanning for new transactions is this n*n type of problem. So you need the transactions proof of the buyers anyway. So why even bother with viewkeys at this point. Its just a distraction. I know there

are people that have something against integrated addresses, but they just havent really thought through how useful they can be for building these more decentralized non custodial marketplaces. This stuff really is the future and it should be easy to build

<Elijah[m]1> "so you just want an web3.xmr..." <- i expanded more on this in the ux channel. Please just let me build it. You will see its usefulness after I built a POC

I'm pro web3.xmr, I just think you're shooting yourself and your future users in the foot

And I did think about what you're trying to build; an ebay for Monero?

I'm doing something similar but a smaller scale/step first

An ecommerce store without Javascript, accepting XMR, and a hidden service

Elijah[m]1: no. you just dont understand what I want to build. And the argument that integrated addresses is bad UX is mood if we let the browser wallet handle everything and you can pay with one click.

I didn't say integrated addresses is bad UX. I said that requiring users to submit proof of transaction is horrible UX

s/mood/moot/

I was saying that removing subaddresses was a bad take

solutions include, provide subaddresses upfront and prove payments to them, use the payment ids (generally discouraged), or use a view-key to prove payment to an address using a utility (not full wallet)

it is heavy to scan a wallet's txs with view-key just to prove a single payment

Elijah[m]1: yes. but this is done by the browserwallet automatically. so its not bad ux. one click. literally one click. I will built a POC it can be done by the way this is how dnm do it as well. look around.

It's done automatically by the browser wallet? Doesn't transaction proof happen after the transaction is included in a block not before?

Maybe I did miss something

Elijah[m]1: I WILL build a POC for a browser wallet on top of the service i am building

so you can understand what i mean

please just let me build it. please 😀

the seller can automatically send payment proof to the server to verify, can be hidden to the user

ok

<rbrunner> "wooders: Yeah, that looks like a..." <- okay so can I use the make payment uri with a 64 bit payment_id or do i need to worry?

the code in wallet2 is law, right? 🙂 github.com/monero-project/monero/bl…6179d/src/wallet/wallet2.cpp#L13732

Not if it's a bug :)

I am pretty sure you won't get through with a long payment id, you will hit a wall somewhere, e.g. in tx construction code inside `wallet2`

if 16 character payment ids are required, then that bug needs fixed

Agreed.

😰😰😰😰😰

ok so the bug does need fixed. until then, can get around the issue by adding a static utility to monero-javascript to generate integrated addresses, and then calling `make_uri` with the integrated address

> <@crypto_grampy:monero.social> Yes I did... What are you building? Something like this but actually using the library that already exists? github.com/RuiSiang/monero-merchant... (full message at libera.ems.host/_matrix/media/r0/do…820654d5fd2db8bbb1df02cf27ffb2deb8a)

Just wanted to forward this so people know what I am working on. If somebody wants to collaborate or have a chat about it. Hit me up! :D

spirobel: would it make sense to create a room focused on this project? I think many would be interested in making it happen

<crypto_grampy[m]> "spirobel: would it make sense to..." <- good idea

pr submitted for make_uri to use short payment id: monero-project/monero #8067

anyone know how this line compiles [1] when the definition clearly expects a byte_stream [2]. this definition changed from v0.17 to master, and I don't know how to make it work with a string now or why this would even compile

[1] github.com/monero-project/monero/bl…orages/levin_abstract_invoke2.h#L69

[2] github.com/monero-project/monero/bl…ude/storages/portable_storage.h#L89

What code can't be compiled ?

Can you show the patch and name parent commit for the patch ?

"anyone know how this line compiles [1] ..." it's disable with `#if 0 ... #endif`

* ... it's disabled ...

woodser[m]: it is using the `byte_slice` constructor, since `byte_slice` has a constructor that accepts a string

byte_slice overload*

this guy: github.com/monero-project/monero/bl…ude/storages/portable_storage.h#L88

UkoeHB: that would make sense, but then I get a compile error linking against the new definition, by passing a string: github.com/monero-ecosystem/monero-…b53/src/utils/monero_utils.cpp#L119

trying to figure out how to make it work with a string, like levin_abstract_invoke2.h [1]

The levin code is commented out, so I'm not sure it is comparable.

Maybe you need to #include byte_slice?

tried that :/

maybe try constructing a byte_slice directly, then passing that to store_to_binary

or `std::move` your bin into the function, since byte_slice wants to use move semantics

"paste.debian.net/hidden/b74abc40" serialize into byte_slice and then copy into string; there is no way to move buffer from byte_slice, since it's designed (for convenience) with internal storage encapsulation

thanks for your help wfaressuissia[m] :)

oh that makes more sense lol

<woodser[m]> "pr submitted for make_uri to use..." <- hm...but shouldnt it be like creating an integrated address instead of add the payment_id on the outside? I wonder how the parse_ui handles this: github.com/monero-project/monero/bl…6179d/src/wallet/wallet2.cpp#L13822 seems like it might be okay if the address is not an integrated address. I just vary of having two ways to have a payment id

in a URI. might lead to more bugs later.

* address. I am just vary

agreed it's weird the payment uri keeps the payment id separate from the address if it's given to it like that

this pr just makes that method only accept 16 character payment ids. the structure can be changed in another pr, if at all

Hey all, I have a question i was hoping I could get some help with in regards to the merkle root verification for each block

Does anyone know where it is implemented/when it is checked when a block is relayed/accepted? Ive looked in handle_block_to_main_chain in src/cryptonote_core/blockchain.cpp, parse_and_validate_block_from_blob and calculate_block_hash in src/cryptonote/cryptonote_core.cpp and ive found little inklings of the merkle root stuff but it doesnt seem like ive found the verification itself

If anyone had any pointers to any functions/areas I should look at it would be greatly appreciated, thank you <3

I made a standalone library to simplify the integration of the 16-word mnemonic seed into Monero. It would be great if someone familiar with monero-wallet-cli could have a look and see if the API is sufficient.

There is one potential issue: since polyseed uses BIP-39 wordlists, the list of supported languages does not exactly match the languages that are currently supported for the electrum seed.

<tevador> "I made a standalone library to..." <- sgp_: might be cool to have cake review this

thanks, will pass along