Hi All I'm new to monero

Welcome. Feel free to browse github issues.

If you get into difficulties hackking, technical questions are welcome here.

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.

I have no dev skills I'm a neurologist however I have completed the blockchain courses from the Linux foundation

I am currently studying for my postdoc

I am here just to follow the news about monero

Ah, then sure, lurk in here. You'll probably get better info about upcoming stuff in #monero-research-lab.

Ok thanks

moneromooo: I tried `-D MONERO_WALLET_CRYPTO_LIBRARY=cn` and got an error `undefined symbol: _ZN10cryptonote27get_transaction_prefix_hashERKNS_18transaction_prefixERN6crypto4hashE`

I link to my cpp bindings a `cryptonote_basic` and `device` static libs that used each other.

If I link in that order: `cryptonote_basic`, `device`, then there will be an error: `undefined symbol: _ZN10cryptonote27get_transaction_prefix_hashERKNS_18transaction_prefixERN6crypto4hashE`

If I link in that order: `device`, `cryptonote_basic`, then there will be an error: `undefined symbol: _ZN2hw10get_deviceERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE`

woodser: I will be grateful if you show me your full link orders

My link order: paste.debian.net/hidden/0217b53f

Did you try copying the wallet one ?

I mean the one from simplewallet in src/simplewallet. It's a top level program that uses all those symbols.

Do you mean to link a libsimplewallet library? I don't understand exactly

No. By "the one" I meant "the lib setup".

You're asking for a lib setup for your code. I'm suggesting using the one from simplewallet.

(plus whatever other code you use, you had a pyhon lib IIRC)

<rogu157[m]> "woodser: I will be grateful if..." <- github.com/monero-ecosystem/monero-…cpp/blob/master/CMakeLists.txt#L312 (the crypto libraries are linked toward the end of the list)

Thank you very much moneromooo woodser . Now I compiled my binding after link missing "cryptonote_format_utils_basic" lib

But now go problems to arguments of parse_and_validate_block_from_blob. I used `py::bytes` but it should be `blobdata_ref&`

This my binding code: paste.debian.net/hidden/60d7b5c6

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.

But now signature is change and it is `bool parse_and_validate_block_from_blob(const blobdata_ref& b_blob, block& b);`.

I used 0.15.0.5... (full message at libera.ems.host/_matrix/media/r0/do…1037d34612d849354946c781f96d02b3fca)

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>`

to typedef `boost::string_ref blobdata_ref`.

I want to understand what type of arguments my Python function should now accept to use `parse_and_validate_block_from_blob`.

Did you lookup the definition of blobdata_ref ?

Yeah, in current version it is: `boost::string_ref blobdata_ref`.

It's boost::string_ref, and IIRC you should be able to pass either std::string or const char*.

const char* implies a terminating NUL BTW.

You don't really want that one for blob contents.

So I think std::string((const char*)address, size) will do, but will probably have an extra copy.

You'll know better what your python types are.

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.

moneromooo: sorry for intterup you again.I took a valid template block, which was returned to me in a response to rpc testnet: paste.debian.net/hidden/4bd21dad.

I pass it to `parse_and_validate_block_from_blob` and it return me that block is not valid.

Code: paste.debian.net/hidden/e448bc8b

Is it some type mismatch ?

* moneromooo: sorry for intterup you again.

I took a valid template block, which was returned to me in a response to rpc testnet: paste.debian.net/hidden/4bd21dad.

I pass it to `parse_and_validate_block_from_blob` and it returns me that block is not valid.

* mismatch ? What I am doing wrong?

Are you passing a hex dump to the parse function ? If so, that's an obvious mistake already.

So stupid, thank you again for your help

Are there any ready made payment gateways i can host and use for Monero?

People in #monero may know. If not, maybe #monero-community.

<ViaLobo[m]> "Are there any ready made payment..." <- Come to #monero-community:monero.social or #monero-community-dev:monero.social

Cryptogramptys hotshop and btcpay come to mind.

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

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

Turns out there's a fair bit of space available. Easily enough for, say, a payment id and a a tx pubkey.

Is there some interest in this, despite the drawback ?

Oh, and obviously an observer cannot tell whether thery's any embedded data, or how much. Otherwise it wouldn't be very interesting.

how badly would the ring size get reduced with ring size 16 when adding e.g. a payment id? do you have a number?

You decrease the effective ring size by 1 for every (even partly filled) 252 bits you embed.

So a tx pubkey would take 2 notches off the ring size. Or 1 off two rings for a typical 2 in tx.

So a tx pubkey and a 8 byte payment id would take 1 off the ring size for a typical 2 in tx.

ok that's not too bad

It's way better than what I tried on BP+ ^_^

moneromooo: Is it only the recipient that can deduce which fake outs are indeed fake?

Or also observers

Only the recipient.

OK, ty

and adding a tx pubkey and 8 byte payment id would not increase the tx size?

or it would?

Well, it'd decrease it, actually, compared to now.

Since you would not need to have those in extra anymore.

Oh, and another drawback (which is also a plus): it's prunable.

So it means if you use it for tx pubkeys, you can't sync pruned blocks or you won't recognize incoming outputs.

I guess that makes it a bit annoying for tx pubkeys then.

so --sync-pruned-blocks would not work ?

It would work, but the wallet would not see the pubkey for 7/8th of old txes. I just thought about this :D

I guess we could make change --sync-pruned-blocks to --sync-pruned-blocks-before-height.

(and you'd use your wallet creation height)

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

But that would only work for nodes that know the wallets that will be connections, in advance (?)

Will be making* connections

@moo

--sync-pruned-blocks works by pulling pruned blocks from peers. So without signatures, mostly (for 7/8th of the chain anyway).

ofrnxmr[m]: yes, the user is expected to know when their wallets were created.

A lower bound's OK.

and --prune-blockchain without --sync-pruned-blocks would work too?

Yes.

er

Actually, it'd prune too early for the wallet... Hmm.

So it'd be a problem too, good point.

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

I'm using monero-rust-sdk

I'm using monero-rpc-rs github.com/monero-ecosystem/monero-…f0b11f6429c6aee381a3680c994bf10e5f2

Apologies if this isn't the correct room, I couldn't find a better place to ask

get_account_address_from_str in src/cryptonote_basic/cryptonote_basic_impl.cpp

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

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

is this the room for that?

oh, indeed, my bad, missread channel name, ill show myself out

lol

Monero mainnet forked?

yup

Congrats, Monero Team 🎉

<spacekitty420[m4> "Proudmuslim: why your name is "..." <- I can DM you regarding this if you like

sure :)

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

You mean the txs did not have the *new* minimum fee, right?

yea we lost about 50tx on fork

correct

Hmmm, quite complex interplay.

also difficult to reproduce on testnet / stagenet since it does not have enough tx

OK. So... the fee should have kicked in on the second fork ?

That's how I understand it as well

But did we even keep the old fee calculation around for doing this?

Yes.

ya I think this should have gotten the old fee: github.com/monero-project/monero/bl…ryptonote_core/blockchain.cpp#L3787

until the second fork

but it should only have gotten the old fee for that check_fee function

something like

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

err, more like: `version == HF_VERSION_PER_BYTE_FEE ? version - 1 : version`

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?

I have seen v5 tx after the hardfork, so should be one-time drop

selsta: confirmed ones?

yes, for example xmrchain.net/tx/8c44477f56ddf1807d5…cd73eb969c394e5756f1e4cbcb103f1fa78

cool, if it was one-off it's not too much of a deal

txs with too low of a fee won't relay during this period, which would include the old default fee

older wallets shouldn't be able to scan txs at this point also fwiw

<jberman[m]> "moneromooo: at the fork height..." <- Ah so this is what happened to my transfer 😅

Sorry :/ Re-tested for tomorrow. Shouldn't be any issues with newer format txs

<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?

is the node you are using definitely updated?

otherwise you might have to rescan your wallet

selsta: No; I'm using a remote node as when I use my own I get this:

Have they moved the rescan button? I can't find it

what happens when you enter the transaction id on xmrchain.net?

make sure to use your own node

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

Oh wait I'm an idiot

It is there... sorry about that 😅

I was checking the wrong wallet

looking up the tx on xmrchain.net is usually the easiest way to figure things out

but making a transaction on fork is always a bit of an edge case

selsta: Yeah it was quite stupid of me to do that