09:49:19 <thanos300693[m]> Hi All I'm new to monero 
09:52:11 <moneromooo> Welcome. Feel free to browse github issues.
09:52:35 <moneromooo> If you get into difficulties hackking, technical questions are welcome here.
09:54:02 <moneromooo> If you're not sure which part of monero you want to contribute to, well, monero itself it C++ mostly, there's the GUI, which is C++/QML/Javascript, Haveno (a P2P exchange) in Java/Javascript, and various related projects on github.com/monero-ecosystem in various languages.
10:20:53 <thanos300693[m]> I have no dev skills I'm a neurologist however I have completed the blockchain courses from the Linux foundation
10:21:10 <thanos300693[m]> I am currently studying for my postdoc 
10:21:30 <thanos300693[m]> I am here just to follow the news about monero
10:23:11 <moneromooo> Ah, then sure, lurk in here. You'll probably get better info about upcoming stuff in #monero-research-lab.
10:23:35 <thanos300693[m]> Ok thanks 
13:02:48 <rogu157[m]> moneromooo: I tried `-D MONERO_WALLET_CRYPTO_LIBRARY=cn` and got an error `undefined symbol: _ZN10cryptonote27get_transaction_prefix_hashERKNS_18transaction_prefixERN6crypto4hashE`
13:02:48 <rogu157[m]> I link to my cpp bindings a `cryptonote_basic` and `device` static libs that used each other.
13:02:48 <rogu157[m]> If I link in that order: `cryptonote_basic`, `device`, then there will be an error: `undefined symbol: _ZN10cryptonote27get_transaction_prefix_hashERKNS_18transaction_prefixERN6crypto4hashE`
13:02:48 <rogu157[m]> If I link in that order: `device`, `cryptonote_basic`, then there will be an error: `undefined symbol: _ZN2hw10get_deviceERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE`
13:03:29 <rogu157[m]> woodser: I will be grateful if you show me your full link orders 
13:07:57 <rogu157[m]> My link order: https://paste.debian.net/hidden/0217b53f/
13:20:22 <moneromooo> Did you try copying the wallet one ?
13:20:52 <moneromooo> I mean the one from simplewallet in src/simplewallet. It's a top level program that uses all those symbols.
13:22:45 <rogu157[m]> Do you mean to link a libsimplewallet library? I don't understand exactly
13:23:20 <moneromooo> No. By "the one" I meant "the lib setup".
13:23:38 <moneromooo> You're asking for a lib setup for your code. I'm suggesting using the one from simplewallet.
13:23:53 <moneromooo> (plus whatever other code you use, you had a pyhon lib IIRC)
13:42:01 <woodser[m]> <rogu157[m]> "woodser: I will be grateful if..." <- https://github.com/monero-ecosystem/monero-cpp/blob/master/CMakeLists.txt#L312 (the crypto libraries are linked toward the end of the list)
14:41:55 <rogu157[m]> Thank you very much moneromooo woodser . Now I compiled my binding after link missing "cryptonote_format_utils_basic" lib 
14:43:02 <rogu157[m]> But now go problems to arguments of parse_and_validate_block_from_blob. I used `py::bytes` but it should be `blobdata_ref&`
14:49:11 <rogu157[m]> This my binding code: https://paste.debian.net/hidden/60d7b5c6/
14:49:11 <rogu157[m]> My previous version used `bool parse_and_validate_block_from_blob(const blobdata& b_blob, block& b);`. I passed a b_blob as `py::bytes` and it already was okay.
14:49:11 <rogu157[m]> But now signature is change and it is `bool parse_and_validate_block_from_blob(const blobdata_ref& b_blob, block& b);`.
14:54:20 <rogu157[m]> I used 0.15.0.5... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/ef7241037d34612d849354946c781f96d02b3fca)
14:57:50 <rogu157[m]> I used 0.15.0.5 before and now use 0.18.1.0. The type of `blobdata_ref` changed from `epee::span<const char>`
14:57:51 <rogu157[m]>  to typedef `boost::string_ref blobdata_ref`.  
14:57:51 <rogu157[m]> I want to understand what type of arguments my Python function should now accept to use `parse_and_validate_block_from_blob`.
15:20:42 <moneromooo> Did you lookup the definition of blobdata_ref ?
15:21:15 <rogu157[m]> Yeah, in current version it is: `boost::string_ref blobdata_ref`.
15:21:22 <moneromooo> It's boost::string_ref, and IIRC you should be able to pass either std::string or const char*.
15:21:47 <moneromooo> const char* implies a terminating NUL BTW.
15:22:12 <moneromooo> You don't really want that one for blob contents.
15:22:39 <moneromooo> So I think std::string((const char*)address, size) will do, but will probably have an extra copy.
15:22:49 <moneromooo> You'll know better what your python types are.
16:25:19 <rogu157[m]> Can someone send an example of a response to getting a block template on testnet? My node is syncing for a long time, this will help me in development. Thank you.
16:44:02 <rogu157[m]> moneromooo: sorry for intterup you again.I took a valid template block, which was returned to me in a response to rpc testnet: https://paste.debian.net/hidden/4bd21dad/.
16:44:02 <rogu157[m]> I pass it to `parse_and_validate_block_from_blob` and it return me that block is not valid.
16:44:21 <rogu157[m]> Code: https://paste.debian.net/hidden/e448bc8b/
16:44:33 <rogu157[m]> Is it some type mismatch ?
16:45:00 <rogu157[m]>  * moneromooo: sorry for intterup you again.
16:45:00 <rogu157[m]> I took a valid template block, which was returned to me in a response to rpc testnet: https://paste.debian.net/hidden/4bd21dad/.
16:45:00 <rogu157[m]> I pass it to `parse_and_validate_block_from_blob` and it returns me that block is not valid.
16:45:14 <rogu157[m]> * mismatch ? What I am doing wrong?
16:56:21 <moneromooo> Are you passing a hex dump to the parse function ? If so, that's an obvious mistake already.
17:08:11 <rogu157[m]> So stupid, thank you again for your help
17:18:50 <ViaLobo[m]> Are there any ready made payment gateways i can host and use for Monero?
17:44:19 <moneromooo> People in #monero may know. If not, maybe #monero-community.
17:49:06 <ofrnxmr[m]> <ViaLobo[m]> "Are there any ready made payment..." <- Come to #monero-community:monero.social  or #monero-community-dev:monero.social 
17:49:06 <ofrnxmr[m]> Cryptogramptys hotshop and btcpay come to mind.
17:49:27 <moneromooo> I have implemented a way to embed arbitrary data in CLSAG, based on an idea by kayabanerve[m]. This totally moots my earlier attempt to embed data in BP+.
17:50:20 <moneromooo> There is a drawback though: the recipient can tell some of the fake outs are indeed fake, so it reduces the effective ring size, but just for the recipient, not for an external observer (though of course the recipient can be an asshole and leak that info).
17:50:49 <moneromooo> Turns out there's a fair bit of space available. Easily enough for, say, a payment id and a a tx pubkey.
17:51:02 <moneromooo> Is there some interest in this, despite the drawback ?
17:53:02 <moneromooo> Oh, and obviously an observer cannot tell whether thery's any embedded data, or how much. Otherwise it wouldn't be very interesting.
17:55:11 <selsta> how badly would the ring size get reduced with ring size 16 when adding e.g. a payment id? do you have a number?
17:56:09 <moneromooo> You decrease the effective ring size by 1 for every (even partly filled) 252 bits you embed.
17:56:46 <moneromooo> So a tx pubkey would take 2 notches off the ring size. Or 1 off two rings for a typical 2 in tx.
17:57:22 <moneromooo> So a tx pubkey and a 8 byte payment id would take 1 off the ring size for a typical 2 in tx.
17:58:03 <selsta> ok that's not too bad
17:58:28 <moneromooo> It's way better than what I tried on BP+ ^_^
17:59:21 <dEBRUYNE> moneromooo: Is it only the recipient that can deduce which fake outs are indeed fake?
17:59:24 <dEBRUYNE> Or also observers
17:59:40 <moneromooo> Only the recipient.
17:59:53 <dEBRUYNE> OK, ty
18:02:29 <selsta> and adding a tx pubkey and 8 byte payment id would not increase the tx size?
18:02:47 <selsta> or it would?
18:03:12 <moneromooo> Well, it'd decrease it, actually, compared to now.
18:03:24 <moneromooo> Since you would not need to have those in extra anymore.
18:04:00 <moneromooo> Oh, and another drawback (which is also a plus): it's prunable.
18:04:38 <moneromooo> So it means if you use it for tx pubkeys,  you can't sync pruned blocks or you won't recognize incoming outputs.
18:05:50 <moneromooo> I guess that makes it a bit annoying for tx pubkeys then.
18:06:12 <selsta> so --sync-pruned-blocks would not work ?
18:06:35 <moneromooo> It would work, but the wallet would not see the pubkey for 7/8th of old txes. I just thought about this :D
18:07:19 <moneromooo> I guess we could make change --sync-pruned-blocks to --sync-pruned-blocks-before-height.
18:07:27 <moneromooo> (and you'd use your wallet creation height)
18:14:33 <selsta> the 1 ring size decrease sounds fine, the pruning stuff confused me a bit now but I don't really understand how --sync-pruned-blocks works in the first place
18:14:42 <ofrnxmr[m]> But that would only work for nodes that know the wallets that will be connections, in advance (?)
18:16:00 <ofrnxmr[m]> Will be making* connections
18:16:00 <ofrnxmr[m]> @moo
18:17:29 <moneromooo> --sync-pruned-blocks works by pulling pruned blocks from peers. So without signatures, mostly (for 7/8th of the chain anyway).
18:17:59 <moneromooo> ofrnxmr[m]: yes, the user is expected to know when their wallets were created. 
18:18:11 <moneromooo> A lower bound's OK.
18:19:12 <selsta> and --prune-blockchain without --sync-pruned-blocks would work too?
18:19:37 <moneromooo> Yes.
18:19:48 <moneromooo> er
18:20:12 <moneromooo> Actually, it'd prune too early for the wallet... Hmm.
18:20:33 <moneromooo> So it'd be a problem too, good point.
18:49:15 <Proudmuslim[m]> I've got a really basic question: I'm attempting to create a Monero tipping bot, and I don't know how to get the public keys from the wallet address
18:49:17 * Proudmuslim[m] uploaded an image: (25KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/grkaPDEqMAFIbboxolEWTBxQ/image.png >
18:49:17 <Proudmuslim[m]> I'm using monero-rust-sdk
18:49:44 <Proudmuslim[m]> I'm using monero-rpc-rs https://github.com/monero-ecosystem/monero-rpc-rs/tree/08bb2f0b11f6429c6aee381a3680c994bf10e5f2
18:50:11 <Proudmuslim[m]> Apologies if this isn't the correct room, I couldn't find a better place to ask
18:51:51 <moneromooo> get_account_address_from_str in src/cryptonote_basic/cryptonote_basic_impl.cpp
18:52:13 <spacekitty420[m4> Proudmuslim: why your name is "Proudmuslim" while apparently for awhile now cryptocurrencies are officially considered "haram" like, against the muslim religion? (am not religious or didnt come from a religious background at all so you can just tell me to fuck off, no worries :))
18:53:25 <spacekitty420[m4> just that few days ago came across that list of countries were cryptocoins are illegal and egypt being one of them apparently for that reason
18:53:41 <nioc> is this the room for that?
18:54:07 <spacekitty420[m4> oh, indeed, my bad, missread channel name, ill show myself out
18:54:13 <moneromooo> lol
18:55:50 <rogu157[m]> Monero mainnet forked?
18:55:59 <spacekitty420[m4> yup
18:56:24 <rogu157[m]> Congrats, Monero Team 🎉
19:03:15 <Proudmuslim[m]> <spacekitty420[m4> "Proudmuslim: why your name is "..." <- I can DM you regarding this if you like
19:03:46 <spacekitty420[m4> sure :)
19:30:44 <jberman[m]> moneromooo: at the fork height old txs got dropped from pools because they didn't have the minimum fee. I tested the fork boundary PR before the fee PR was merged. I should have retested more extensively. Crappy mistake
19:32:25 <rbrunner> You mean the txs did not have the *new* minimum fee, right?
19:32:38 <selsta> yea we lost about 50tx on fork
19:32:38 <jberman[m]> correct
19:33:11 <rbrunner> Hmmm, quite complex interplay.
19:33:33 <selsta> also difficult to reproduce on testnet / stagenet since it does not have enough tx
19:35:00 <moneromooo> OK. So... the fee should have kicked in on the second fork ?
19:35:44 <rbrunner> That's how I understand it as well
19:36:09 <rbrunner> But did we even keep the old fee calculation around for doing this?
19:36:16 <moneromooo> Yes.
19:37:26 <jberman[m]> ya I think this should have gotten the old fee: https://github.com/monero-project/monero/blob/b6a029f222abada36c7bc6c65899a4ac969d7dee/src/cryptonote_core/blockchain.cpp#L3787
19:38:28 <jberman[m]> until the second fork
19:38:54 <jberman[m]> but it should only have gotten the old fee for that check_fee function
19:40:25 <jberman[m]> something like
19:40:28 <jberman[m]> uint64_t fee_per_byte = get_dynamic_base_fee(base_reward, use_long_term_median_in_fee ? std::min<uint64_t>(median, m_long_term_effective_median_block_weight) : median, version == HF_VERSION_PER_BYTE_FEE ? version - 1 : HF_VERSION_PER_BYTE_FEE);
19:41:06 <jberman[m]> err, more like: `version == HF_VERSION_PER_BYTE_FEE ? version - 1 : version`
20:13:32 <binaryFate> jberman[m]: was it just a one-time drop off of these old submitted txs at fork height, or is it also not possible now to submit old style txs during interim period?
20:16:26 <selsta> I have seen v5 tx after the hardfork, so should be one-time drop
20:17:25 <binaryFate> selsta: confirmed ones?
20:17:58 <selsta> yes, for example https://xmrchain.net/tx/8c44477f56ddf1807d509c157ac32cd73eb969c394e5756f1e4cbcb103f1fa78
20:19:21 <binaryFate> cool, if it was one-off it's not too much of a deal
20:22:18 <jberman[m]> txs with too low of a fee won't relay during this period, which would include the old default fee
20:23:15 <jberman[m]> older wallets shouldn't be able to scan txs at this point also fwiw
21:04:31 <Proudmuslim[m]> <jberman[m]> "moneromooo: at the fork height..." <- Ah so this is what happened to my transfer 😅
21:11:12 <jberman[m]> Sorry :/ Re-tested for tomorrow. Shouldn't be any issues with newer format txs
22:00:38 <Proudmuslim[m]> <jberman[m]> "Sorry :/ Re-tested for tomorrow...." <- It's no problem! I'm currently getting this error when I try to resend it- do you know if/when this will be resolved?
22:00:39 * Proudmuslim[m] uploaded an image: (60KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/naCdqZwHUmbfRwcGhJxgGKoB/image.png >
22:01:21 <selsta> is the node you are using definitely updated?
22:02:22 <selsta> otherwise you might have to rescan your wallet
22:02:38 <Proudmuslim[m]> selsta: No; I'm using a remote node as when I use my own I get this:
22:02:41 * Proudmuslim[m] uploaded an image: (64KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/uBAqnbtpeMYIjnwIjGVTIIfX/image.png >
22:02:52 <Proudmuslim[m]> Have they moved the rescan button? I can't find it 
22:03:15 <selsta> what happens when you enter the transaction id on xmrchain.net?
22:04:00 <selsta> make sure to use your own node
22:06:49 <Proudmuslim[m]> selsta: It... shows up? I'm confused- I was moving the XMR to another wallet of mine and it hasn't showed up there yet 
22:06:57 <Proudmuslim[m]> Oh wait I'm an idiot 
22:07:05 <Proudmuslim[m]> It is there... sorry about that 😅
22:07:10 <Proudmuslim[m]> I was checking the wrong wallet
22:09:59 <selsta> looking up the tx on xmrchain.net is usually the easiest way to figure things out
22:10:15 <selsta> but making a transaction on fork is always a bit of an edge case
22:11:46 <Proudmuslim[m]> selsta: Yeah it was quite stupid of me to do that