am i just mining my own chain over here?

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

is it possible to use monero-wallet-rpc to construct a transaction manually selecting outputs to use in the ring?

from what ive seen in the rpc docs im guessing the answer is no

bonedaddy: That would potentially lead to fingerprinting too

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?

normo: hmm, works here

wait, that might be because my p2pstate.bin has peers saved

Yup.

Try ./monerod --add-priority-node 176.9.0.187

with --testnet

That's the node of testnet.xmrchain.net, hopefully, which can pass some peers to you

Er ... right :)

Thanks, I'll try that.

Can I alsojust delete p2pstate.bin?

There have been periods of months in the past without any seed nodes running. Testnet could definitely use some more love

Should not matter

According to community.xmr.to/xmr-countdown and community.xmr.to/xmr-countdown/stagenet the fork on mainnet will happen before the fork on stagenet.

With the priority node I get: I [176.9.0.187:28080 OUT] [priority]Failed to HANDSHAKE with peer 176.9.0.187:28080

Over and over again.

set_log 1, and you'll see if you're dropping the connection and why.

If you don't see, the other one is dropping.

^ second the comment from moneromooo, some more review of 6745 would be nice.

I'm seeing "verRctMGSimple/verRctCLSAGSimple failed for input 0" for b1bd9dd8fdb18bdd7871713fd014f63679c93fa9d93074ce69a00cdbefd0b44d, can't sync past that...

Anyone has that tx in their chain ?

(and is updated to current masteR)

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

moneromooo, for that tx i get: Found in blockchain at height 1544011

on the xmrhchain box

and what i think is the seed node

OK. Rebuilding from master just in case, not sure where I was on when I built that.

Though it did create a CLSAG tx so... hmm.

Oh wait I can't build master due to db format. Gnfngfngmfdgan.

that’s my tx

(first CLSAG tx on testnet)

remember the rpc port is open on xmrchain.net testnet node if thats useful

WTF, a whole file conflict ? Seriously -_-

Ah, it's the CLSAG patches. Can be skipped.

gingeropolous: btw do you know why testnet explorer fails on CLSAG tx? does moneroexamples have to update it?

probably. do u see anything in their dev branch or whatever that would make it work?

i did a quick perusal and didn't see anything

ah rbrunner reported it already as an issue

Looks like decode_ringct is erroring out on unknown type.

Does paste.debian.net/hidden/7182f990 help ?

gingeropolous: can you test ^ ? else I will set up a local testnet explorer later

well im a genius and can't apply the patch. is it to onion explorer or to monerod?

onion explorer

error: src/tools.cpp: patch does not apply

search the `case rct::RCTTypeBulletproof2` line in src/tools.cpp

add `case rct::RCTTypeCLSAG:` beneath it

compiling

oh goddamnit

... my libs from the monero dir must be effd

Extremely Fun For Debugging ?

Nice, rebased work branch syncs happily. Phew.

.. /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&)':

so thats what happens with onion explorer with that modded line compiling against master

Anyone is welcome to connect to my testnet node: `45.20.210.161:28080`

Its up to date and working fine since the fork

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

Feel free to PR its addition (src/p2p/net_node.inl)

gingeropolous: that's not the error itself

The error should be next line (unless it's a "required from" line, skip those)

device_default.cpp:(.text+0x119): undefined reference to `monero_crypto_amd64_64_24k_generate_subaddress_public_key'

did you checkout latest master?

thought i did

Looks like supercop. You need to link to... wallet-crypto

ill delete the build dir and try again

oh u meant master of explorer

yes

how can I force monero to build with submodule unbound? -D INSTALL_VENDORED_LIBUNBOUND=ON ?

sudo rm /usr/include/unbound.h /usr/lib*/libundound*

Sounds violent, but it's what I do :)

(well, mv and mv back)

hmm, not important anyway, will use system unbound again

Oh THAT again... I fixed it somewhere IIRC. Let me hunt it down...

gingeropolous: on my system latest master version of onion-monero-blockchain-explorer works fine with CLSAG

without any patches

oh nice

> Tx size: 1.4102 kB

:)

where's a tx

i got it up

someones mining the shit out of the chain

nice !

yay it works

now, monero to the moon

selsta: let me know if it actually works, it comes not from the monero repo per se. If it does, I'll PR.

ah I missed the patch

will try

.merges

the PR that makes ringsize a bajillion

oh the bot beat me to it

Maybe we should leave 6111 to luigi1111

Ah crap. It's missing a one. Gonna be a while.

should we add trezor PR to merge bot too? or wait a bit?

It seems simple enough. If it's needed now, I have no objection.

moneromooo: which unbound commit are you on?

the patch does not look correct

wait

the patch is confusing, first it adds stuff then it gets removed again, I get it now

hmmm

gui

:D

Oh does it. It's three patches, I just took the diffs off them and paste them in a row.

I'll clean that up if I PR, thanks :)

there is still this super old PR open to update unbound submodule

I gave up on that one.

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)

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

With the patch ?

with irccloud.com/pastebin/fXH18khF

rm CMakeCache.txt ?

was a clean build, unless there is cmake stuff inside external/unbound that I also have to reset

Otherwise, I guess it might be another of the patches on gitea.

will try to set the submodule to the latest unbound release and check if it compiles

yea that does not work lol

moneromooo: Thanks for the info!

normo: did you manage to resolve your testnet issue?

I asked before today,but I'll give it another try: According to community.xmr.to/xmr-countdown and 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?

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.

Might be the correct height, the problem could be the slow hash rate, maybe. The network cannot reach it in time.

PR a change to it to whatever you think is appropriate.

It's in src/hardforks/hardforks.cpp

Change both v13 and v14, to happen a few blocks to a day later.

binaryFate: ^ you're ok with that ? (also anyone who uses stagenet)

Will do.

<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

I think normo is gone, anyway I'll pass it on, he's working with me on xmrto. We'll take care of it.

monero-project/unbound #16 (since nobody will likely see it otherwise as it's on a deserted repo)

And I'll have a submodule update once that's merged.

Yes. I had that exact error. Awesome!

hello im currently writing any auto-churning service that runs locally using monero-wallet-rpc, what

ops sent that too early

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

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

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)

UkoeHB: good idea I will add that to the list

also the current way fees are set up, they can leak timing delays between 'tx creation' and 'tx submission'

interesting i hadn't thought of that before

in the future we may reduce the granularity of fees to mitigate timing analysis, but who knows if or when that would get released

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

web.getmonero.org/library/Zero-to-Monero-2-0-0.pdf section 7.3.4

thanks

and this is ongoing research on fees monero-project/research-lab #70

nice, tyvm