There's currently no release which will use BP+ on stagenet, right?

kayabaNerve: no

Didn't think so :/ Did check releases beforehand yet was hoping there'd at least be a branch I didn't know of

you have to compile master

but stagenet also isn't forked yet

Sorry, I did not mean stagenet. I meant regtest. I'm just a dunce on terminology

master would be fine though

Also, I doubt it's an issue as it's worked thus far, yet I did want to point out zeroCommit doesn't commit with a mask of 0. It commits with mask of 1 :/ Broke my implementation of it

I'm working on a payment processing system and am fairly sure there is a problem with my monero code, but I'm not familiar enough with the internals to really know. If someone sends two transactions to the same address in my system and they both confirm in the same block, what exactly happens when my system forwards the first transaction specifying that subaddress index? Does the rest go to some change address? Does the rest get

locked?

Each of the incoming transactions will generate one output, that you own

In general, you should think in terms of transaction outputs rather than subaddresses

merope: Is there an RPC method to specify the output to spend from instead of the subaddress index?

I don't see a way to do that in the wallet RPC transfer method

There should be the sweep_single if you want to spend exactly one output by itself

But I'm not sure that's a good solution, in general

Ideally I would like to split some of it off to go to a second address

Split some of the amount you got from the first transaction?

For each transaction I'd like to split an amount off

so in the previous example, I'd like to forward each of the two outputs that were sent to the same subaddress to a given address and split some off to another address

Does it matter if you wait a little and then spend both outputs at once? Or do you want to spend each output as soon as possible?

waiting to send does not matter

Hmmm, I'm looking at sweep_all, but I think it only supports one destination address

And if you use transfer, then you'll be left with dust

I guess the easiest solution would be to transfer the amount you want to split off, then sweep_single the change output from that transfer to the other address

I would need to wait for the funds to unlock again with that method, right?

yes, at least 10 blocks before you could sweep the change from the first transfer

and after using transfer, would the output I would use for sweep_single be different because of change or something?

If you don't mind leaving behind some dust, then you could just do a single transfer to both destinations at once, and do a little extra work to estimate the fee as close as you can

That first transfer would spend as many outputs as necessary to match the requested transfer amount, and create a two new outputs: one for the recipient, and one change output with the difference for yourself

<WillMorrison[m]> "I'm working on a payment..." <- are you just handling the situation where a person doesn't send the exact amount?

cryptogrampy[m]: I'm handling the situation where an end user sends multiple transactions quickly, like if they send the wrong amount and then immediately send the rest

WillMorrison[m]: I think it's extremely uncommon for merchants to allow multiple transactions for payment.. I'd drop that feature very low on the priority list if it was me :)

for this particular system I'm trying to support monitoring created addresses forever

Just ask for exact payment 🤷

people don't follow instructions :(

people don't, but wallets do

do a clickable monero payment uri and a qr code with the amount encoded

^

what if you wanted an address to accept donations, not payments for a service? You would want that to be static and constantly monitored, and two people may send at the same time

Payment requests are a great way to avoid ambiguity, if you can

WillMorrison[m]: integrated addresses solve this :)

So you're trying to do a system that returns back any extra amount, and the forwards the rest to your "consolidation" address?

merope: Yes, the system just forwards money that arrives and notifies the person using the system through callbacks

Keep in mind that the user will have to manually provide you with a return address, otherwise you'll have no idea to where to send back the extra money

cryptogrampy[m]: in what way? Yes they are static but does it solve other problems?

WillMorrison[m]: you can generate a random payment id for each donor, their payments go to the same address at the end of the day, and the payments are very distinguishable from eachother from a checking-for-payment standpoint

cryptogrampy[m]: thanks for the insight, I need to read about integrated addresses

people are very excited to deprecate them but they work really well for many merchant scenarios

surely there's gotta be a way to make the subaddress thingy work just as well

monero rpc wallet + --tx-notify + get_transfer_by_txid 🥹

plowsof[m]: that's what I currently have

the problem is what to do after knowing about the transaction

Trezor code for HF15 is already PR'd: monero-project/monero #8299

Was ledger ever notified? I think selsta mentioned he would, but may have been someone else.

Friendly reminder we have a checklist with things completed and remaining to be done as a part of the hard-fork.

Is there a way to sanity check the fee on the wallet side that's a closer match than just setting a hardcoded XMR value?

Is it possible to reuse the same algo used to calculate the fee by the daemon in the wallet also

Where would the wallet get the data to calculate it ?

Electrum wallets show a warning when the fee is > a certain % threshold of the funds you want to send (rather than a hardcoded value)

i want to send 1 xmr but the fee is 1.2 xmr = 120% fee warning

i know selsta has been looking into a network crawler to ' attempt a transaction without broadcasting - check the fee - change the remote node repeat ' to try and find the bad apples

When spending from an integrated address that has many outputs tied to it, does it behave like a subaddress in that monero chooses which outputs to spend from based on what makes the transaction most secure?

For example, if there is a 0.5 XMR output and a 1 XMR output, and I call wallet RPC transfer method for 0.45 XMR. Is there a chance the full balance of the subaddress gets locked?

The standard address is a special case, which replaces the 0,0 subadress. It's also handled separately for hte crypto side, for backward compatibility. Output choice is not any different though.

<moneromooo> "Where would the wallet get the..." <- The wallet would get all the data and sign the transaction, but then check to see if the fee is a common (allowed) multiplier before actually broadcasting?

For the second line, IIRC it'll try to find a single or two outs that match the amount needed. Whether it keeps at 1 or tries to use the second depends on your wallet settings.

sgp_: multiplier of what exactly ?

I mean, the base fee is calculated from chain data. If your chain isn't trusted, then you can't derive a trusted value.

You could make probabilistic guesses though. Like, the block reward won't be > 1 monero, the block size is roughly the accumulated size of hte txes we got for htat block.

But the daemon can still lie to you. Omit txes, add fake txes. Lie about the block reward.

And if you start having that kind of rule in the wallet to try and guess whether the chain data is right, because you don't want to verify the chain, well...

Asking more than one daemon would give you higher assurance, but still a kludge, and still probabilistic.

And since light wallets (or at least one, cake IIRC) seem to have their own centralized daemons anyway...

And mymonero.

What about asking the main monero seed nodes, if available?

They're inherently "trusted" for bootstrapping the network, anyway

most people realistically use the default nodes set in the wallet, yes

(Which is not a good thing per se, but kinda unavoidable)

So the wallet would optionally (as a setting) connect to one/two of those nodes and ask them for a fee estimate, and if that number diverges too much from the response then raise a warning for the user

Doesn't Electrum server handle this issue for bitcoin? As in, connect to many electrum servers to reduce the effect of malicious nodes?

"hey nodes, how much would you bid to relay my tx for me?" ...\

<merope> "What about asking the main..." <- Wouldn't that just make the seednodes a big point of failure

Also, point of attack

As I said, it would be an opt-in optional check - and it shouldn't actually stop the user from submitting the tx, just raise a warning flag

If the seed nodes were malicious, the worst that could happen (in regards to the fee estimation) would be an unnecessary warning which the user could always disable

And maybe you could specify which node(s) to ask, instead of the default seed nodes

Previously you had malicious nodes, now you have malicious nodes and the seednodes getting ddosed

I mean... nothing stops them from getting ddosed right now. But I see how such a feature could significantly increase their traffic/load

merope: There's also not a real reason to ddos them, if you implement a check, malicious nodes become less effective. If someone already cares enough to spin up malicious nodes, they might also just ddos to keep them at near current levels of effectiveness

But ultimately there's no "deeper" solution here: either you use a node you can trust (whether somebody else's or your own), or you have to make do with whatever public node you have and remember to check the fee before spending

Right but that check has to get the number from somewhere, and that somewhere is another node

Why don't we pay for chainlink /s

15:08 <sethforprivacy> Was ledger ever notified? I think selsta mentioned he would, but may have been someone else. <-- I was in contact with them about Ledger Nano S+ the past day but didn't write yet about BP+

didn't want 2 topics at once

selsta: Thanks, do you mind writing them about that or putting me in touch with them?

sethforprivacy: see PM

Thanks

Sata ssd or nvme ssd for node? Or does it make any difference? Thanks

not much difference. and that's not a -dev question\

<sgp_> "Is there a way to sanity check..." <- it might make sense to just throw a modal warning if users switch from the default 'Looks like you're switching from the default node; make sure this node is either your own, or a node you trust. Find out more on Monero.com/trust-your-node'

I think it's probably better to educate users on malicious nodes than abstract it away using a hardcoded tx value or pinging a 'trusted' node

if education worked, bitcoin's "privacy" would work

It's like pissing in the wind. People do not care.

Well, most people who use cryptocurrencies. Most tend to use a number of cryptocurrencies, which have no privacy. Privacy is irrelevant for them. It's just a distinguisher for a market.

They just want to use it as they use any random shite. Send to echange. Get from exchange. Buy. Sell. Forget.

And at some point in the future we'll all be using dogecoin for life because some morons played with dogecoin for fun and everything else got discarded because people don't have any forward vision.

Govts and corps will laugh their asses off at us morons who fucked ourselves when we could have selected a private currency but instead went for a dog.

We're fucking morons.

Wait. This is -dev. Sorry.

We're the 2014 year of the linux desktop of cryptocurrencies. I tend to go both ways on the in-app educational aspect. I happened to pull a competitor privacy coin mobile wallet the other day that allows users to choose between surveillance transactions (type X) or private transactions (type Y), but just calls them X and Y in the app- nothing about whether or not one is private or public and nothing about what data goes onto the

blockchain when they use the different transaction types

sure, tell us how you really feel ...

You could probably calculate a moving average of past transaction fees, and throw a prompt if there's a significant deviation

this could be provided as a wallet-rpc option where everyone agrees on what a safe deviation actually is to make it easy for anyone to use

No need for moving average, just check which fee per byte would get you in the latest mined block. Anything more than 5x above that is unnecessary and should trigger a warning.

i.e. check latest block's transactions and find the one with lowest fee per byte

if the block wasn't full, then the lowest possible fee is enough

sech1: i like this

plus it works right away without having to make a few tx's

the problem is, the wallet gets all this information from the node it connects to, so we're back to square one

Maybe average the lowest fee from the last x blocks (10?).

Would just the last block be enough (assuming the node was malicious)

all data is sent from the node so this is all pointless

then we can connect to multiple nodes but then it gets complicated again when the solution is to not connect to malicious nodes in the first place

sech1: this might be a dumb question, but can you even make a successful transaction on a node that has 'bad' blocks?

<@sech1:libera.chat> i.e. check latest block's transactions and find the one with lowest fee per byte. Might not work since some TX fees are subsidized

subsidized?

> > <@sech1:libera.chat> the problem is, the wallet gets all this information from the node it connects to, so we're back to square one

>

> this might be a dumb question, but can you even make a successful transaction on a node that has 'bad' blocks?

Yeah as long as it fits concensus rules and is broadcatsed

sech11 It doesn't happen as much in Monero, but some mining pools will send their own transactions through for little to no fees

Happens a lot with coins with high fees

I think fee issues could be partly mitigated by UX: wallets should have a really big and obvious confirmation process for setting the tx fee, with an extra warning if the fee is some large percent of the transfer amount.

ah, subsidized = mined with low or 0 fee. I'm not sure about economics of that because pools reduce miners' income when blocks are full. So miners pay a fee anyway, just not directly.

something something header chain

download blockchain from standard p2p mishmash of various peers, verify header chain, use that. begin chain validation in background

"use that" meaning use that for tx creation and push. if blockchain is borkt, network will reject

network will reject a transaction formed from a borkt blockchain

So a simple minimum will not work, but maybe you calculate lower 25% quartile of TX fees

oof the truth hurts

<gingeropolous> "if education worked, bitcoin's..." <- 100%

Can you spend from a specific integrated address or only from the standard address that they all funnel to?

you can't send from an integrated address

Hey does anyone here know how to exclude all anonymous namespaces from Doxygen?

Getting real tired of this:

I can do it manually for each slice of code but it's annoying