00:57:10 <kayabaNerve> There's currently no release which will use BP+ on stagenet, right?
01:02:33 <selsta> kayabaNerve: no
01:03:12 <kayabaNerve> Didn't think so :/ Did check releases beforehand yet was hoping there'd at least be a branch I didn't know of
01:03:20 <selsta> you have to compile master
01:03:27 <selsta> but stagenet also isn't forked yet
01:52:35 <kayabaNerve> Sorry, I did not mean stagenet. I meant regtest. I'm just a dunce on terminology
01:52:41 <kayabaNerve> master would be fine though
01:54:46 <kayabaNerve> 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
02:59:29 <WillMorrison[m]> 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
02:59:29 <WillMorrison[m]> locked?
03:01:03 <merope> Each of the incoming transactions will generate one output, that you own
03:01:46 <merope> In general, you should think in terms of transaction outputs rather than subaddresses
03:02:11 <WillMorrison[m]> merope: Is there an RPC method to specify the output to spend from instead of the subaddress index?
03:02:31 <WillMorrison[m]> I don't see a way to do that in the wallet RPC transfer method
03:02:58 <merope> There should be the sweep_single if you want to spend exactly one output by itself
03:03:38 <merope> But I'm not sure that's a good solution, in general
03:03:43 <WillMorrison[m]> Ideally I would like to split some of it off to go to a second address
03:04:37 <merope> Split some of the amount you got from the first transaction?
03:05:04 <WillMorrison[m]> For each transaction I'd like to split an amount off 
03:05:30 <WillMorrison[m]> 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
03:08:44 <merope> 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?
03:09:11 <WillMorrison[m]> waiting to send does not matter 
03:12:38 <merope> Hmmm, I'm looking at sweep_all, but I think it only supports one destination address
03:13:01 <merope> And if you use transfer, then you'll be left with dust
03:14:03 <merope> 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
03:14:49 <WillMorrison[m]> I would need to wait for the funds to unlock again with that method, right?
03:15:11 <merope> yes, at least 10 blocks before you could sweep the change from the first transfer
03:16:34 <WillMorrison[m]> and after using transfer, would the output I would use for sweep_single be different because of change or something?
03:16:36 <merope> 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
03:18:13 <merope> 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
03:18:15 <cryptogrampy[m]> <WillMorrison[m]> "I'm working on a payment..." <- are you just handling the situation where a person doesn't send the exact amount?
03:19:08 <WillMorrison[m]> 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
03:21:29 <cryptogrampy[m]> 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 :) 
03:22:27 <WillMorrison[m]> for this particular system I'm trying to support monitoring created addresses forever 
03:22:34 <cryptogrampy[m]> Just ask for exact payment 🤷
03:22:43 <WillMorrison[m]> people don't follow instructions :(
03:22:53 <cryptogrampy[m]> people don't, but wallets do
03:23:25 <cryptogrampy[m]> do a clickable monero payment uri and a qr code with the amount encoded
03:23:34 <merope> ^
03:23:48 <WillMorrison[m]> 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
03:23:53 <merope> Payment requests are a great way to avoid ambiguity, if you can
03:25:57 <cryptogrampy[m]> WillMorrison[m]: integrated addresses solve this :)
03:25:57 <merope> So you're trying to do a system that returns back any extra amount, and the forwards the rest to your "consolidation" address?
03:26:16 <WillMorrison[m]> merope: Yes, the system just forwards money that arrives and notifies the person using the system through callbacks
03:26:43 <merope> 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
03:26:47 <WillMorrison[m]> cryptogrampy[m]: in what way? Yes they are static but does it solve other problems?
03:27:36 <cryptogrampy[m]> 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
03:29:45 <WillMorrison[m]> cryptogrampy[m]: thanks for the insight, I need to read about integrated addresses
03:30:45 <cryptogrampy[m]> people are very excited to deprecate them but they work really well for many merchant scenarios
03:32:08 <gingeropolous> surely there's gotta be a way to make the subaddress thingy work just as well
03:33:35 <plowsof[m]> monero rpc wallet + --tx-notify + get_transfer_by_txid 🥹
03:33:44 <WillMorrison[m]> plowsof[m]: that's what I currently have
03:33:53 <WillMorrison[m]> the problem is what to do after knowing about the transaction
13:07:15 <sethforprivacy> Trezor code for HF15 is already PR'd: https://github.com/monero-project/monero/pull/8299
13:08:35 <sethforprivacy> Was ledger ever notified? I think selsta mentioned he would, but may have been someone else.
13:08:53 <sethforprivacy> Friendly reminder we have a checklist with things completed and remaining to be done as a part of the hard-fork.
13:09:05 <sethforprivacy> https://github.com/monero-project/meta/issues/690
13:16:14 <sgp_> 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?
13:16:31 <sgp_> Is it possible to reuse the same algo used to calculate the fee by the daemon in the wallet also
13:19:08 <moneromooo> Where would the wallet get the data to calculate it ?
13:32:02 <plowsof[m]> Electrum wallets show a warning when the fee is > a certain % threshold of the funds you want to send (rather than a hardcoded value)
13:32:17 <plowsof[m]> i want to send 1 xmr but the fee is 1.2 xmr = 120% fee warning
13:40:29 <plowsof[m]> 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 
13:54:01 <WillMorrison[m]> 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?
13:54:01 <WillMorrison[m]> 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?
14:18:33 <moneromooo> 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.
14:19:19 <sgp_> <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?
14:19:28 <moneromooo> 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.
14:19:55 <moneromooo> sgp_: multiplier of what exactly ?
14:20:57 <moneromooo> I mean, the base fee is calculated from chain data. If your chain isn't trusted, then you can't derive a trusted value.
14:23:41 <moneromooo> 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.
14:24:12 <moneromooo> But the daemon can still lie to you. Omit txes, add fake txes. Lie about the block reward.
14:24:55 <moneromooo> 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...
14:25:39 <moneromooo> Asking more than one daemon would give you higher assurance, but still a kludge, and still probabilistic.
14:26:07 <moneromooo> And since light wallets (or at least one, cake IIRC) seem to have their own centralized daemons anyway...
14:26:16 <moneromooo> And mymonero.
14:29:44 <merope> What about asking the main monero seed nodes, if available?
14:29:50 <merope> They're inherently "trusted" for bootstrapping the network, anyway
14:29:55 <sgp_> most people realistically use the default nodes set in the wallet, yes
14:30:20 <merope> (Which is not a good thing per se, but kinda unavoidable)
14:31:52 <merope> 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
14:36:44 <Rucknium[m]> Doesn't Electrum server handle this issue for bitcoin? As in, connect to many electrum servers to reduce the effect of malicious nodes?
15:32:32 <hyc> "hey nodes, how much would you bid to relay my tx for me?" ...\
15:41:14 <monerobull[m]> <merope> "What about asking the main..." <- Wouldn't that just make the seednodes a big point of failure
15:41:27 <monerobull[m]> Also, point of attack
15:42:49 <merope> 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
15:43:50 <merope> 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
15:44:12 <merope> And maybe you could specify which node(s) to ask, instead of the default seed nodes
15:44:13 <monerobull[m]> Previously you had malicious nodes, now you have malicious nodes and the seednodes getting ddosed
15:45:02 <merope> I mean... nothing stops them from getting ddosed right now. But I see how such a feature could significantly increase their traffic/load
15:46:43 <monerobull[m]> 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
15:46:52 <merope> 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
15:48:03 <merope> Right but that check has to get the number from somewhere, and that somewhere is another node
15:48:42 <monerobull[m]> Why don't we pay for chainlink /s
16:13:31 <selsta> 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+
16:13:49 <selsta> didn't want 2 topics at once
16:17:57 <sethforprivacy> selsta: Thanks, do you mind writing them about that or putting me in touch with them?
16:43:04 <selsta> sethforprivacy: see PM
17:01:13 <sethforprivacy> Thanks
17:34:32 <viresinnumeris[m> Sata ssd or nvme ssd for node? Or does it make any difference? Thanks
17:35:02 <hyc> not much difference. and that's not a -dev question\
17:58:40 <cryptogrampy[m]> <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'
18:06:39 <cryptogrampy[m]> 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
18:08:19 <gingeropolous> if education worked, bitcoin's "privacy" would work
18:08:21 <moneromooo> It's like pissing in the wind. People do not care.
18:09:32 <moneromooo> 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.
18:10:04 <moneromooo> They just want to use it as they use any random shite. Send to echange. Get from exchange. Buy. Sell. Forget.
18:11:06 <moneromooo> 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.
18:11:48 <moneromooo> 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.
18:11:54 <moneromooo> We're fucking morons.
18:12:03 <moneromooo> Wait. This is -dev. Sorry.
18:16:07 <cryptogrampy[m]> 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
18:16:08 <cryptogrampy[m]> blockchain when they use the different transaction types
18:17:16 <hyc> sure, tell us how you really feel ...
18:24:13 <cryptogrampy[m]> You could probably calculate a moving average of past transaction fees, and throw a prompt if there's a significant deviation
18:25:53 <cryptogrampy[m]> 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
18:33:37 <sech1> 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.
18:34:02 <sech1> i.e. check latest block's transactions and find the one with lowest fee per byte
18:34:39 <sech1> if the block wasn't full, then the lowest possible fee is enough
18:35:42 <cryptogrampy[m]> sech1: i like this
18:36:06 <cryptogrampy[m]> plus it works right away without having to make a few tx's
18:37:30 <sech1> the problem is, the wallet gets all this information from the node it connects to, so we're back to square one
18:39:08 <w[m]> Maybe average the lowest fee from the last x blocks (10?).
18:39:08 <w[m]> Would just the last block be enough (assuming the node was malicious)
18:39:30 <selsta> all data is sent from the node so this is all pointless
18:39:58 <selsta> 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
18:40:29 <cryptogrampy[m]> sech1: this might be a dumb question, but can you even make a successful transaction on a node that has 'bad' blocks?
18:40:41 <jeffro256[m]> <@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 
18:41:08 <sech1> subsidized?
18:42:08 <jeffro256[m]> > > <@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
18:42:08 <jeffro256[m]> > 
18:42:08 <jeffro256[m]> > this might be a dumb question, but can you even make a successful transaction on a node that has 'bad' blocks?
18:42:08 <jeffro256[m]> Yeah as long as it fits concensus rules and is broadcatsed
18:43:23 <jeffro256[m]> sech11 It doesn't happen as much in Monero, but some mining pools will send their own transactions through for little to no fees
18:43:38 <jeffro256[m]> Happens a lot with coins with high fees
18:44:00 <UkoeHB> 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.
18:46:55 <sech1> 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.
18:53:47 <gingeropolous> something something header chain
18:55:50 <gingeropolous> download blockchain from standard p2p mishmash of various peers, verify header chain, use that. begin chain validation in background
18:56:25 <gingeropolous> "use that" meaning use that for tx creation and push. if blockchain is borkt, network will reject
18:58:28 <gingeropolous> network will reject a transaction formed from a borkt blockchain
19:42:17 <jeffro256[m]> So a simple minimum will not work, but maybe you calculate lower 25% quartile of TX fees
20:46:39 <reeemuru[m]> oof the truth hurts
20:51:57 <r4v3r23[m]> <gingeropolous> "if education worked, bitcoin's..." <- 100%
20:54:47 <WillMorrison[m]> Can you spend from a specific integrated address or only from the standard address that they all funnel to?
20:58:14 <selsta> you can't send from an integrated address
23:47:53 <jeffro256[m]> Hey does anyone here know how to exclude all anonymous namespaces from Doxygen?
23:48:00 <jeffro256[m]> Getting real tired of this:
23:48:40 * jeffro256[m] uploaded an image: (521KiB) < https://libera.ems.host/_matrix/media/r0/download/monero.social/IeRlLfzHZfYNsHjeDfLDDVLf/Screenshot%20from%202022-04-28%2018-46-03.png >
23:50:16 <jeffro256[m]> I can do it manually for each slice of code but it's annoying