03:02:37 <gingeropolous> am i just mining my own chain over here?
03:02:55 <gingeropolous> Height: 1544277/1544277 (100.0%) on testnet, mining at 4.06 kH/s, net hash 4.03 kH/s, v13 (next fork in 0.5 days), 1(out)+1(in) connections, uptime 0d 8h 55m 48s
06:37:53 <bonedaddy> is it possible to use monero-wallet-rpc to construct a transaction manually selecting outputs to use in the ring?
06:38:10 <bonedaddy> from what ive seen in the rpc docs im guessing the answer is no
10:20:46 <dEBRUYNE> bonedaddy: That would potentially lead to fingerprinting too
10:34:10 <normo> I updated my testnet node to the current `master`, but after restarting it cannot connect to the single seed node and therefore cannot be used. Is there a way to make it work properly again?
10:43:23 <selsta> normo: hmm, works here
10:43:47 <selsta> wait, that might be because my p2pstate.bin has peers saved
10:43:53 <rbrunner> Yup.
10:44:17 <rbrunner> Try ./monerod --add-priority-node 176.9.0.187
10:44:38 <selsta> with --testnet
10:44:43 <rbrunner> That's the node of testnet.xmrchain.net, hopefully, which can pass some peers to you
10:45:01 <rbrunner> Er ... right :)
10:45:22 <normo> Thanks, I'll try that.
10:45:36 <normo> Can I alsojust delete p2pstate.bin?
10:45:41 <rbrunner> There have been periods of months in the past without any seed nodes running. Testnet could definitely use some more love
10:45:51 <rbrunner> Should not matter
10:56:32 <normo> According to https://community.xmr.to/xmr-countdown/ and https://community.xmr.to/xmr-countdown/stagenet/ the fork on mainnet will happen before the fork on stagenet.
11:13:14 <normo> With the priority node I get: I [176.9.0.187:28080 OUT] [priority]Failed to HANDSHAKE with peer 176.9.0.187:28080
11:13:20 <normo> Over and over again.
11:16:23 <moneromooo> set_log 1, and you'll see if you're dropping the connection and why.
11:16:33 <moneromooo> If you don't see, the other one is dropping.
11:18:37 <TheCharlatan> ^ second the comment from moneromooo, some more review of 6745 would be nice.
11:39:04 <moneromooo> I'm seeing "verRctMGSimple/verRctCLSAGSimple failed for input 0" for b1bd9dd8fdb18bdd7871713fd014f63679c93fa9d93074ce69a00cdbefd0b44d, can't sync past that...
11:39:14 <moneromooo> Anyone has that tx in their chain ?
11:40:11 <moneromooo> (and is updated to current masteR)
11:43:41 <gingeropolous> i have a wopping 3 peers on both the xmrchain.net node and the old explorer node which is now the seed peer I think
11:45:51 <gingeropolous> moneromooo, for that tx i get: Found in blockchain at height 1544011
11:46:49 <gingeropolous> on the xmrhchain box
11:47:29 <gingeropolous> and what i think is the seed node
11:48:16 <moneromooo> OK. Rebuilding from master just in case, not sure where I was on when I built that.
11:48:31 <moneromooo> Though it did create a CLSAG tx so... hmm.
11:48:51 <moneromooo> Oh wait I can't build master due to db format. Gnfngfngmfdgan.
11:49:37 <selsta> that’s my tx
11:49:54 <selsta> (first CLSAG tx on testnet)
11:50:39 <gingeropolous> remember the rpc port is open on xmrchain.net testnet node if thats useful
11:52:49 <moneromooo> WTF, a whole file conflict ? Seriously -_-
11:53:37 <moneromooo> Ah, it's the CLSAG patches. Can be skipped.
11:58:33 <selsta> gingeropolous: btw do you know why testnet explorer fails on CLSAG tx? does moneroexamples have to update it?
12:03:27 <gingeropolous> probably. do u see anything in their dev branch or whatever that would make it work?
12:03:32 <gingeropolous> i did a quick perusal and didn't see anything
12:05:43 <gingeropolous> ah rbrunner reported it already as an issue
12:06:24 <moneromooo> Looks like decode_ringct is erroring out on unknown type.
12:08:13 <moneromooo> Does https://paste.debian.net/hidden/7182f990/ help ?
12:17:11 <selsta> gingeropolous: can you test ^ ? else I will set up a local testnet explorer later
12:17:41 <gingeropolous> well im a genius and can't apply the patch. is it to onion explorer or to monerod?
12:17:48 <selsta> onion explorer
12:18:01 <gingeropolous> error: src/tools.cpp: patch does not apply
12:18:27 <selsta> search the `case rct::RCTTypeBulletproof2` line in src/tools.cpp
12:18:44 <selsta> add `case rct::RCTTypeCLSAG:` beneath it
12:24:20 <gingeropolous> compiling
12:26:05 <gingeropolous> oh goddamnit
12:26:23 <gingeropolous>  ... my libs from the monero dir must be effd
12:28:55 <moneromooo> Extremely Fun For Debugging ?
12:35:03 <moneromooo> Nice, rebased work branch syncs happily. Phew.
12:57:06 <gingeropolous> .. /home/xmrchain/monero/build/release/src/device/libdevice.a(device_default.cpp.o): In function `hw::core::device_default::derive_subaddress_public_key(crypto::public_key const&, crypto::key_derivation const&, unsigned long, crypto::public_key&)':
12:57:29 <gingeropolous> so thats what happens with onion explorer with that modded line compiling against master
13:01:12 <sethsimmons> Anyone is welcome to connect to my testnet node: `45.20.210.161:28080`
13:01:18 <sethsimmons> Its up to date and working fine since the fork
13:01:33 <sethsimmons> And I will do my best to keep it up/up to date moving forward, if we want to add it to a seed node list or something
13:02:48 <moneromooo> Feel free to PR its addition (src/p2p/net_node.inl)
13:02:59 <moneromooo> gingeropolous: that's not the error itself
13:03:43 <moneromooo> The error should be next line (unless it's a "required from" line, skip those)
13:49:08 <gingeropolous> device_default.cpp:(.text+0x119): undefined reference to `monero_crypto_amd64_64_24k_generate_subaddress_public_key'
13:49:44 <selsta> did you checkout latest master?
13:50:18 <gingeropolous> thought i did
13:50:59 <moneromooo> Looks like supercop. You need to link to... wallet-crypto
13:51:23 <selsta> https://github.com/moneroexamples/onion-monero-blockchain-explorer/commit/09653279d19307d7db64f19563808bcad209f7ce
13:51:41 <gingeropolous> ill delete the build dir and try again
13:52:07 <gingeropolous> oh u meant master of explorer
13:52:17 <selsta> yes
13:54:37 <selsta> how can I force monero to build with submodule unbound? -D INSTALL_VENDORED_LIBUNBOUND=ON ?
13:55:04 <moneromooo> sudo rm /usr/include/unbound.h /usr/lib*/libundound*
13:57:25 <moneromooo> Sounds violent, but it's what I do :)
13:57:32 <moneromooo> (well, mv and mv back)
13:59:50 <selsta> https://www.irccloud.com/pastebin/HnhLB12J/
14:00:11 <selsta> hmm, not important anyway, will use system unbound again
14:06:52 <moneromooo> Oh THAT again... I fixed it somewhere IIRC. Let me hunt it down...
14:08:55 <moneromooo> https://paste.debian.net/hidden/8dd83688/
14:09:15 <selsta> gingeropolous: on my system latest master version of onion-monero-blockchain-explorer works fine with CLSAG
14:09:20 <selsta> without any patches
14:09:34 <gingeropolous> oh nice
14:10:44 <selsta> > Tx size: 1.4102 kB
14:10:45 <selsta> :)
14:11:10 <gingeropolous> where's a tx
14:11:17 <gingeropolous> i got it up
14:11:33 <selsta> https://testnet.xmrchain.net/search?value=b1bd9dd8fdb18bdd7871713fd014f63679c93fa9d93074ce69a00cdbefd0b44d
14:11:45 <gingeropolous> someones mining the shit out of the chain
14:12:05 <gingeropolous> nice !
14:12:07 <gingeropolous> yay it works
14:12:19 <gingeropolous> now, monero to the moon
14:16:31 <moneromooo> selsta: let me know if it actually works, it comes not from the monero repo per se. If it does, I'll PR.
14:17:18 <selsta> ah I missed the patch
14:17:21 <selsta> will try
14:18:08 <Snipa> .merges
14:18:22 -xmr-pr- 6111
14:18:25 <gingeropolous> the PR that makes ringsize a bajillion
14:18:29 <gingeropolous> oh the bot beat me to it
14:18:43 <moneromooo> Maybe we should leave 6111 to luigi1111
14:19:14 <moneromooo> Ah crap. It's missing a one. Gonna be a while.
14:19:44 <selsta> should we add trezor PR to merge bot too? or wait a bit?
14:20:19 <moneromooo> It seems simple enough. If it's needed now, I have no objection.
14:31:41 <selsta> moneromooo: which unbound commit are you on?
14:32:07 <selsta> the patch does not look correct
14:32:22 <selsta> wait
14:32:49 <selsta> the patch is confusing, first it adds stuff then it gets removed again, I get it now
14:32:50 <luigi1111w> hmmm
14:32:54 <selsta> gui
14:32:57 <selsta> :D
14:33:18 <moneromooo> Oh does it. It's three patches, I just took the diffs off them and paste them in a row.
14:33:32 <moneromooo> I'll clean that up if I PR, thanks :)
14:34:36 <selsta> there is still this super old PR open to update unbound submodule
14:34:47 <moneromooo> I gave up on that one.
14:39:11 <dsc_> Re: vendored unbound - is there way to skip this library completely somehow? I've noticed that `INSTALL_VENDORED_LIBUNBOUND` is OFF by default, but I was still getting an *vendored* unbound compile error. I guess my question is: Why is there a vendored unbound - did it get forked, and how much has it diverged (a little / a lot)
14:40:16 <moneromooo> IIRC it was because we wanted to patch security bugs because it was releasing way too slowly. But it was anonimal, who's MIA, so it's probably the opposite now...
14:40:16 <selsta> https://www.irccloud.com/pastebin/Lx09U9wc/
14:40:42 <moneromooo> With the patch ?
14:41:02 <selsta> with  https://www.irccloud.com/pastebin/fXH18khF/
14:41:24 <moneromooo> rm CMakeCache.txt ?
14:41:27 * moneromooo kicks cmake
14:41:53 <selsta> was a clean build, unless there is cmake stuff inside external/unbound that I also have to reset
14:42:03 <moneromooo> Otherwise, I guess it might be another of the patches on gitea.
14:46:04 <selsta> will try to set the submodule to the latest unbound release and check if it compiles
14:51:55 <selsta> yea that does not work lol
14:59:27 <dsc_> moneromooo: Thanks for the info!
16:50:23 <selsta> normo: did you manage to resolve your testnet issue?
19:39:21 <normo> I asked before today,but I'll give it another try: According to https://community.xmr.to/xmr-countdown/ and https://community.xmr.to/xmr-countdown/stagenet/ the fork on mainnet will happen before the fork on stagenet. This seems to be wrong. Will there be an update of the heights?
19:44:18 <moneromooo> Not for mainnet. For stagenet, if people want, sure. I thought I'd set it two weeks before mainnet, maybe I got the wrong height off some explorer.
20:58:12 <normo> Might be the correct height, the problem could be the slow hash rate, maybe. The network cannot reach it in time.
21:07:23 <moneromooo> PR a change to it to whatever you think is appropriate.
21:07:31 <moneromooo> It's in src/hardforks/hardforks.cpp
21:07:52 <moneromooo> Change both v13 and v14, to happen a few blocks to a day later.
21:08:25 <moneromooo> binaryFate: ^ you're ok with that ? (also anyone who uses stagenet)
21:22:19 <normo> Will do.
22:01:14 -xmr-pr- normoes opened pull request #6800: Let stagenet hardfork happen before mainnet.
22:01:14 -xmr-pr- > https://github.com/monero-project/monero/pull/6800
22:06:04 <binaryFate> <moneromooo> binaryFate: ^ you're ok with that ? (also anyone who uses stagenet) <-- yeah totally. normo let's keep an eye when we get closer to fork date and refine fork height if need be, so we keep the roughly 2 weeks prior to mainnet
22:08:00 <binaryFate> I think normo is gone, anyway I'll pass it on, he's working with me on xmrto. We'll take care of it.
22:47:42 <moneromooo> https://github.com/monero-project/unbound/pull/16 (since nobody will likely see it otherwise as it's on a deserted repo)
22:48:04 <moneromooo> And I'll have a submodule update once that's merged.
22:51:29 <dsc_> Yes. I had that exact error. Awesome!
23:12:06 <bonedaddy> hello im currently writing any auto-churning service that runs locally using monero-wallet-rpc, what
23:12:10 <bonedaddy> ops sent that too early
23:15:26 <bonedaddy> hello im currently writing any auto-churning service that runs locally using monero-wallet-rpc, what kind of feedback would people want from something like this? Eseentially how it works is it periodically loops checking specified wallets for unlocked funds, once the unlocked funds reaches a threshold the monero-wallet-rpc transfer RPC is called, except it is set to not relay the transaction and simply return the metadata. This metadata is
23:15:26 <bonedaddy> persisted locally and the transction is scheduled to be relayed at a random time in a specified interval, using a random transaction priority. at a minimum it shows the source address, the amount being churned, the destination churn address, as well as the delay before the tx is relayed. im thinking of including graphs that show the included dummy outputs similar to that graph shown during the ciphertrace interview
23:33:14 <UkoeHB_> bonedaddy: you may want to consider using a non-uniform random distribution for churn, since decoy ring members are chosen from non-uniform distribution (it's a gamma distribution)
23:33:56 <bonedaddy> UkoeHB: good idea I will add that to the list
23:34:58 <UkoeHB_> also the current way fees are set up, they can leak timing delays between 'tx creation' and 'tx submission'
23:36:38 <bonedaddy> interesting i hadn't thought of that before
23:37:18 <UkoeHB_> in the future we may reduce the granularity of fees to mitigate timing analysis, but who knows if or when that would get released
23:37:27 <bonedaddy> do you have a link or something to documentation that talks about tx fee determination? i imagine its probably some sampling of the mempool and the average transaction at any one point
23:38:01 <UkoeHB_> https://web.getmonero.org/library/Zero-to-Monero-2-0-0.pdf section 7.3.4
23:38:07 <bonedaddy> thanks
23:38:30 <UkoeHB_> and this is ongoing research on fees https://github.com/monero-project/research-lab/issues/70
23:39:46 <bonedaddy> nice, tyvm