01:10:40 <gingeropolous> xmrchain node, (v0.17.0.0-83f35d5db), uptime 34d 21h 12m 26s . gonna build current master and run that now
01:13:02 <gingeropolous> huh, the hash id when u start monero didn't change. ah well.
04:09:31 <joe-molested-hun> Hi all, just FYI I've set up a bounty for that decoy selection bug: https://bounties.monero.social/posts/33/fix-monero-gui-decoy-selection-bug-monero-gui-issue-3733
04:09:41 <joe-molested-hun> @selsta in particular
09:39:21 <woodser[m]> I'm getting an error compiling against monero-project master that I don't get on the v0.17 branch:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/0045409b54f51cff390488cf4624d41e30fe5fa5)
09:39:35 <woodser[m]> 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)
09:39:54 <woodser[m]> but then levin_abstract_invoke2.h still calls `store_to_binary()` with a string and compiles
09:40:03 <woodser[m]> so two questions: how can I use the updated method to write to a string? how is levin_abstract_invoke2.h compiling?
13:32:47 <spirobel[m]> https://github.com/monero-ecosystem/monero-javascript/blob/73c8c8b569f246201aa00f06564892f136cd490e/src/test/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
13:32:47 <spirobel[m]> on the monero wallet rpc which expects a 16 char hex string to make an integrated_address: https://www.getmonero.org/resources/developer-guides/wallet-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. 
13:33:38 <spirobel[m]> s/generated/generate/
13:38:54 <spirobel[m]> 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: https://github.com/monero-project/monero/blob/6d94953be259c6bf4a1407ec552a570a66b6179d/src/wallet/wallet2.cpp#L13732 
13:50:17 <spirobel[m]> 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) https://www.getmonero.org/resources/developer-guides/wallet-rpc.html#make_integrated_address Which is the right one, 16 or 64 or can I use both?
14:34:50 <woodser[m]> you can first create the integrated address and retrieve the randomly generated payment id:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/ee66a5cef620f5e518b6237f44e2a64a32777c22)
14:35:08 <woodser[m]> then from that you can create a payment uri with the integrated address:
14:35:08 <woodser[m]> `let paymentUri = await wallet.createPaymentUri(new MoneroTxConfig().setAddress(integratedAddress.getIntegratedAddress()).setAmount(new BigInteger("425000000000"))`
14:35:08 <woodser[m]> which yields this payment uri: `{"destinations":[{"address":"5DtiRu1pUvKdnw7NPafr5ZdCRj1Qa4SYN56cgfozAwCeMj7TZazWe1bip8A5UCPKK7RrpGaP97vsxHabwYEWUCWQgpn7GkAGGnRMhAH4ow","amount":425000000000}]}`
14:37:44 <woodser[m]> er, actually this would be the payment uri: monero:5DtiRu1pUvKdnw7NPafr5ZdCRj1Qa4SYN56cgfozAwCeMj7TZazWe1bip8A5UCPKK7RrpGaP97vsxHabwYEWUCWQgpn7GkAGGnRMhAH4ow?tx_amount=0.425000000000
14:42:12 <woodser[m]> 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
14:42:15 <woodser[m]> and `make_uri` only allows 64 character payment ids though
14:42:31 <woodser[m]> I was thinking only 64 character payment ids are allowed now
14:43:59 <woodser[m]> also note integrated addresses are discouraged over subaddresses nowadays
14:48:32 <spirobel[m]> 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
14:48:33 <spirobel[m]> 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.
14:51:26 <spirobel[m]> <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
14:51:26 <spirobel[m]> server. 
14:52:24 <woodser[m]> <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
14:53:14 <woodser[m]> 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?
14:55:18 <woodser[m]> creating the MoneroWalletFull object is a matter of downloading and initializing a 5.24 mb wasm file. shouldn't be prohibitively expensive
14:56:16 <spirobel[m]> woodser[m]: oh thats not good. Seems like I need to write a function by hand to make integrated addresses from normal addresses
14:57:19 <woodser[m]> ah yes that's expensive if every client downloads it as part of a web app
14:57:30 <spirobel[m]> Its running server side
14:58:39 <woodser[m]> ah then the file size shouldn't matter?
14:59:47 <spirobel[m]> 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
15:00:24 <spirobel[m]> and I might generate huge amounts of integrated addresses in short order. Its just adding a random number to a string, right?
15:01:32 <spirobel[m]> 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
15:01:37 <spirobel[m]> but maybe I am thinking too far
15:03:59 <woodser[m]> 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.
15:03:59 <woodser[m]> 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 
15:05:11 <woodser[m]> <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
15:06:19 <woodser[m]> 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
15:07:32 <spirobel[m]> 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? 
15:08:31 <spirobel[m]> 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
15:08:43 <spirobel[m]> but it least it would be possible 
15:09:55 <spirobel[m]> s/it/at/
15:14:26 <woodser[m]> 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
15:15:26 <woodser[m]> yes `checkTxKey()` and `checkTxProof()` lets you verify payments to external wallets
15:19:45 <spirobel[m]> woodser[m]: amazing I also thought about this again. I can use https://github.com/monero-ecosystem/monero-javascript/blob/73c8c8b569f246201aa00f06564892f136cd490e/src/test/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
15:19:45 <spirobel[m]> these utility functions should be separated from the wallet. It would help unfuck my brain haha
15:22:36 <spirobel[m]> <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
15:22:36 <spirobel[m]> just using some utility functions)
15:22:50 <spirobel[m]> s/only/online/
15:23:27 <spirobel[m]> Thanks a lot for you help! Its fun exploring this together haha!
15:23:33 <spirobel[m]> 👍️
15:24:00 <woodser[m]> spirobel[m]: yeah this should work
15:24:42 <spirobel[m]> s/only/online/, s/either//
15:25:45 <woodser[m]> it should be possible to derive receiving addresses from a view-key without scanning and this could also be incorporated into the library
15:25:52 <woodser[m]> happy to help, feel free to DM
16:06:37 <Elijah[m]1> 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
16:06:37 <Elijah[m]1> side, upon 10 confirmations or whatever, the monero will be auto sent to the address the seller provided. 
16:06:43 <Elijah[m]1> s/logn/long/
16:07:13 <Elijah[m]1> s/logn/long/, s/Then/On/, s/on//
16:07:25 <Elijah[m]1> 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
16:07:25 <Elijah[m]1> 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
16:07:25 <Elijah[m]1> 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. /
16:09:47 <Elijah[m]1> 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
16:09:47 <Elijah[m]1> 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
16:09:47 <Elijah[m]1> 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. /
16:10:19 <Elijah[m]1> 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
16:10:19 <Elijah[m]1> 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
16:10:19 <Elijah[m]1> 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. /
16:17:02 <gingeropolous> 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 
16:27:01 <rbrunner> 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?"
16:27:30 <rbrunner> I think you got that exactly backwards: Only "short payment ids" (16) are supported, the "long payment ids" (64) are gone
16:34:38 <spirobel[m]> <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. 
16:35:13 <Elijah[m]1> What's the race condition?
16:35:55 <spirobel[m]> Elijah[m]1: buy product multiple times and supply the same transaction proof multiple times.
16:36:00 <spirobel[m]> (for the same transaction)
16:36:11 <spirobel[m]> it will make the implementation a lot more complex
16:37:01 <Elijah[m]1> Well if you want to allow multiple purchases for each product, each ORDER should have an associated subaddress
16:38:12 <spirobel[m]> 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. 
16:38:59 <Elijah[m]1> What's wrong with the wallet-rpc?
16:41:16 <spirobel[m]> 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
16:41:16 <spirobel[m]> monero-javascript and makepaymenturi and 64 bit random payment id
16:43:29 <spirobel[m]> 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 
16:43:56 <Elijah[m]1> Bad take
16:44:36 <Elijah[m]1> In the short-term prioritizing throughput/productivity is okay, but in the long-term user UX should be a priority.
16:44:53 <Elijah[m]1> Requiring the user to do more than just sending Monero is bad UX
16:45:13 <Elijah[m]1> But if the priority is subjective (namely get it out ASAP)
16:45:47 <spirobel[m]> 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 
16:45:56 <spirobel[m]> think about eth3.js
16:46:04 <spirobel[m]> we need to make xmr3.js
16:48:11 <spirobel[m]> you also need to think about developer ux. there is no way to build what i want to build with subaddresses at the moment.
16:48:32 <spirobel[m]> nobody thought of handling large amount of viewkeys on a server
16:48:39 <spirobel[m]> and make it non cumbersome
16:50:18 <Lyza> I don't know shit about fuck but pretty sure MyMonero handles loads of viewkeys server side you could see what they do
16:50:44 <woodser[m]> <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: https://github.com/monero-project/monero/blob/6d94953be259c6bf4a1407ec552a570a66b6179d/src/wallet/wallet2.cpp#L13732
16:51:07 <Elijah[m]1> spirobel you said in the UX channel that you don't want to get the vieww guys from the sellers.
16:51:10 <spirobel[m]> 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.
16:51:33 <Elijah[m]1> 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./
16:51:34 <spirobel[m]> Elijah[m]1: yes. because its not necessary 
16:51:34 <Elijah[m]1> s/vieww/view/, s/guys/keys/
16:51:41 <Elijah[m]1> so why are you using it as an argument?
16:52:20 <Elijah[m]1> so you just want an web3.xmr then?
16:52:41 <endogenic> spirobel[m] haven't you seen monero-lws?
16:53:27 <endogenic> man is there a UX channel for monero on IRC?
16:54:07 <endogenic> oh
16:54:08 <endogenic> nice
16:56:58 <woodser[m]> 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
16:57:07 <woodser[m]> then have the buyers prove payments to those subaddresses
16:57:36 <rbrunner> 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
16:57:37 <rbrunner> https://github.com/monero-project/monero/blob/6d94953be259c6bf4a1407ec552a570a66b6179d/src/simplewallet/simplewallet.cpp#L136
16:58:28 <spirobel[m]> <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
16:58:28 <spirobel[m]> 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 
16:59:04 <spirobel[m]> <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
16:59:39 <Elijah[m]1> I'm pro web3.xmr, I just think you're shooting yourself and your future users in the foot
16:59:56 <Elijah[m]1> And I did think about what you're trying to build; an ebay for Monero?
17:00:06 <Elijah[m]1> I'm doing something similar but a smaller scale/step first
17:00:28 <Elijah[m]1> An ecommerce store without Javascript, accepting XMR, and a hidden service
17:00:29 <spirobel[m]> 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.
17:00:55 <Elijah[m]1> I didn't say integrated addresses is bad UX. I said that requiring users to submit proof of transaction is horrible UX
17:00:55 <spirobel[m]> s/mood/moot/
17:01:13 <Elijah[m]1> I was saying that removing subaddresses was a bad take
17:01:34 <woodser[m]> 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)
17:01:40 <woodser[m]> it is heavy to scan a wallet's txs with view-key just to prove a single payment
17:01:46 <spirobel[m]> 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.
17:02:36 <Elijah[m]1> It's done automatically by the browser wallet? Doesn't transaction proof happen after the transaction is included in a block not before?
17:02:53 <Elijah[m]1> Maybe I did miss something
17:03:04 <spirobel[m]> Elijah[m]1: I WILL build a POC for a browser wallet on top of the service i am building
17:03:12 <spirobel[m]> so you can understand what i mean
17:03:26 <spirobel[m]> please just let me build it. please 😀
17:03:44 <woodser[m]> the seller can automatically send payment proof to the server to verify, can be hidden to the user
17:03:44 <Elijah[m]1> ok
17:05:28 <spirobel[m]> <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?
17:07:30 <spirobel[m]> the code in wallet2 is law, right? 🙂  https://github.com/monero-project/monero/blob/6d94953be259c6bf4a1407ec552a570a66b6179d/src/wallet/wallet2.cpp#L13732
17:08:07 <rbrunner> Not if it's a bug :)
17:09:14 <rbrunner> 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`
17:09:41 <woodser[m]> if 16 character payment ids are required, then that bug needs fixed
17:10:28 <rbrunner> Agreed.
17:11:23 <rbrunner> https://web.getmonero.org/de/2019/06/04/Long-Payment-ID-Deprecation.html
17:11:55 * spirobel[m] uploaded an image: (214KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/eNZpphhnRpnNMsvSokntlpMU/image.png >
17:12:03 <spirobel[m]> 😰😰😰😰😰
17:12:43 <woodser[m]> 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
17:36:03 <spirobel[m]> > <@crypto_grampy:monero.social> Yes I did... What are you building?  Something like this but actually using the library that already exists? https://github.com/RuiSiang/monero-merchant... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/262b3820654d5fd2db8bbb1df02cf27ffb2deb8a)
17:36:43 <spirobel[m]> 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 
17:37:54 <crypto_grampy[m]> spirobel: would it make sense to create a room focused on this project?  I think many would be interested in making it happen
18:10:16 <spirobel[m]> <crypto_grampy[m]> "spirobel: would it make sense to..." <- good idea
19:02:49 <woodser[m]> pr submitted for make_uri to use short payment id: https://github.com/monero-project/monero/pull/8067
19:09:10 <woodser[m]> 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
19:09:10 <woodser[m]> [1] https://github.com/monero-project/monero/blob/6d94953be259c6bf4a1407ec552a570a66b6179d/contrib/epee/include/storages/levin_abstract_invoke2.h#L69
19:09:10 <woodser[m]> [2] https://github.com/monero-project/monero/blob/6d94953be259c6bf4a1407ec552a570a66b6179d/contrib/epee/include/storages/portable_storage.h#L89
19:11:29 <wfaressuissia> What code can't be compiled ?
19:11:46 <wfaressuissia> Can you show the patch and name parent commit for the patch ?
19:15:02 <wfaressuissia> "anyone know how this line compiles [1]  ..." it's disable with `#if 0 ... #endif`
19:15:16 <wfaressuissia> * ... it's disabled ...
19:15:20 <UkoeHB> woodser[m]: it is using the `byte_slice` constructor, since `byte_slice` has a constructor that accepts a string
19:15:36 <UkoeHB> byte_slice overload*
19:15:50 <UkoeHB> this guy: https://github.com/monero-project/monero/blob/6d94953be259c6bf4a1407ec552a570a66b6179d/contrib/epee/include/storages/portable_storage.h#L88
19:20:50 <woodser[m]> UkoeHB: that would make sense, but then I get a compile error linking against the new definition, by passing a string: https://github.com/monero-ecosystem/monero-cpp/blob/e665590e3966798c33de45c94f7f31a95e4d6b53/src/utils/monero_utils.cpp#L119
19:22:05 <woodser[m]> trying to figure out how to make it work with a string, like levin_abstract_invoke2.h [1]
19:22:45 <UkoeHB> The levin code is commented out, so I'm not sure it is comparable.
19:23:33 <UkoeHB> Maybe you need to #include byte_slice?
19:24:23 <woodser[m]> tried that :/
19:27:09 <UkoeHB> maybe try constructing a byte_slice directly, then passing that to store_to_binary
19:33:22 <UkoeHB> or `std::move` your bin into the function, since byte_slice wants to use move semantics
19:36:28 <wfaressuissia> "https://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
19:41:54 <woodser[m]> thanks for your help wfaressuissia[m] :)
19:43:26 <UkoeHB> oh that makes more sense lol
20:02:02 <spirobel[m]> <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: https://github.com/monero-project/monero/blob/6d94953be259c6bf4a1407ec552a570a66b6179d/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
20:02:02 <spirobel[m]> in a URI. might lead to more bugs later.
20:16:34 <spirobel[m]> * address. I am just vary
20:34:59 <woodser[m]> agreed it's weird the payment uri keeps the payment id separate from the address if it's given to it like that
20:35:17 <woodser[m]> this pr just makes that method only accept 16 character payment ids. the structure can be changed in another pr, if at all
21:03:36 <hitomifujiko[m]> 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
21:05:46 <hitomifujiko[m]> 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
21:06:03 <hitomifujiko[m]> If anyone had any pointers to any functions/areas I should look at it would be greatly appreciated, thank you <3
22:39:26 <tevador> 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.
22:39:28 <tevador> https://github.com/tevador/polyseed
22:41:47 <tevador> 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.
22:52:45 <crypto_grampy[m]> <tevador> "I made a standalone library to..." <- sgp_: might be cool to have cake review this
22:54:20 <sgp_> thanks, will pass along