hyc sech1 can you try leaving and rejoining

luigi1111w done

got it now

I've got p2pool running on testnet (2 nodes, 2 wallets so far). It runs with 1 second block time because I want to catch synchronization bugs faster. Instructions will be later today, but for now you can watch for 0in/2out blocks on testnet.xmrchain.net

test instructions are published: github.com/SChernykh/p2pool

hyc selsta moneromooo or whoever else was interested ^^^

sech1: not important now but cmake has some warnings paste.debian.net/hidden/6de62345

I'm not strong with cmake

I think you'll get this warning if libzmq or libuv is not found

syntax looks correct so no idea

Odd, I see libuv and more in external already, and we need to install it ?

I have both libs

"debug" is followed by specifier "debug" means that whatever was between them is an empty string

right

libuv and stuff in external are just collecting dust there for now

I used them to build a fully static binary in Alpine

not collecting dust, I still use headers from these folders

So... we have to install the exact same version as those headers ?

No need for exact same version

just headers need to be compatible

I need to switch to git submodules and build everything locally, one more thing in a todo list

paste.debian.net/hidden/80ece6d0 fails here currently

Interesting. What's your gcc version?

clang 12.0.5

right, clang is not supported yet

add INT_ENTRY(unsigned long) in log.h on line 168

that also explains your cmake warnings

I just don't have stuff for clang there

selsta what OS version is this?

macOS 11.5.2

currently stuck here paste.debian.net/hidden/7bd9b27e

clang is retarded

sizeof(value.s) should be available to the compiler there

I'll try to remove that part entirely, it's not so important

I don't have a Mac so it's 100% untested there, but wait until I update log.h

paste.debian.net/hidden/637d6381 is needed to build here (Fedora).

Oh, I left a debug trace...

Is it expected to spew lots of "not enough data to verify block at height" messages ?

I have accepted shares from xmrig.

I also disabled FULL_MEM and LARGE_PAGES, in case I goofed that one up.

"not enough data" is ok

it means it haven't synced required blocks yet

it will verify this block later when it has enough data, obviously :)

Well, still hasn't stopped spewing.

It needs to sync 4000+ blocks first

currently down to height ~20230

OK, it's counting down indeed, at 21k now.

it syncs all blocks and then starts verifying from bottom to top

xmrig submitting shares means you're already mining from height 0, but it will reorg once you're synced

Nice, it's stopped spewing now.

I see "3 wallets" messages in the og

A new job a second on the xmrig side, whee.

*log

2 of those are mine, I suppose 3rd is yours

yes, it's running at 1 block/second

I see 3 too. That'd be consensus on the share chain side, right ?

yes

you can type "status" command in the p2pool console if you have it open

it'll probably be quickly buried under other log output

but you can open p2pool.log and check it out there

also "loglevel 2" to stop spam

but I recommend to run at maximum loglevel 5 to catch everything in case we get a chain split or bug or something

damn, status command doesn't print how many wallets are in the window. I forgot to add it

Nice, first coinbase.

0.001710546230 testnet XMR

it will grow to match your hashrate after PPLNS window passes

~36 minutes

Since those wallet addresses are public, it'd need to have a large mention of such in the README at some point. ie, don't use for exchanges etc.

you can't use exchange deposit addresses for mining

because these are subaddresses

but yeah, I need to add it to README for the release

I thought of how to avoid making miner addresses public but couldn't come up with good solution. Miners could publish stealth addresses to pay to, but they depend on output index, so it's doesn't work for p2ppool

So one can estimate every address' hash rate too.

Anyway, nifty. Thanks for doing this :)

yes, and this estimate would be possible even with stealth addresses

because txkey only changes after pool finds Monero block

Public miner addresses are a bit of downside here. Miners will have to create entire new wallets and use them only for mining.

by the way, each pool share is a Monero block template and you can see BLOCK_BROADCAST (pruned) in the log. Pruned means coinbase transaction is skipped

because it can grow up to 80 KB and can be restored from sidechain data because it's part of consensus

I installed libuv1-dev and it still says UV_LIBRARY is missing

paste.debian.net/hidden/637d6381 helped me with that.

moneromoooo your port 37890 is not open btw

my node can't connect to you

I know. It's a VPN provider.

cool thx

I must warn that I'm a noob with cmake mumbo-jumbo

feel free to make a PR to fix things

I think mine's a bodge. It should have worked, since monero has that kind of setup too.

I also needed libbbsd here on ubuntu21

moneromoooo what's your hashrate btw?

Looks like about 40 H/s.

Seems high. Depends what other VMs are doing, it'll likely go down to ~25.

(I set xmrig to light mode)

cool

and you got a payout almost immediately, this what p2pool is about

I run 2 nodes: first at 475 h/s and second at 963 h/s

so p2pool difficulty checks out, currently at 1460

"I also disabled FULL_MEM and LARGE_PAGES" do you mean you're running p2pool in light mode too?

Yes.

cool, it's good for testing

Can't afford the 2 GB per. Too many VMs.

light mode takes more time to verify blocks, more latency

Presumably, if someone were to run a p2pool instance with number of blocks set to, say, 100k, the typical payout amount would be 25x smaller, right ?

you probably can't fit 100k outputs in a 300 KB block

2160 outputs are already 80 KB

you can ramp it up to ~7000 but then there will be almost no space left for other transactions

also, you need 100k wallets if PPLNS window is 100k

p2pool combines payouts for shares with the same wallet address

Good :)

I did not realize that the share chain size itself was "merged" by wallet address. That's interesting.

I wonder if that opens a DoS vector.

Alice has a lot of the p2pool hash. If she gets unlucky in the last 20 minutes, she might decide to switch mining to many addresses, to flush the unlucky part quicker.

I don't get it. Alice still needs to mine blocks with the same difficulty no matter what wallet addresses she uses

Yes.

But if her shares are spready among N addresses, then the share chain "flushes" quicker.

no it doesn't

it flushes by block height

PPLNS window is calculated using block heights

Oh, I re-read and misundersood. Makes more sense now.

Is the merging consensus ?

ie, you check for uniqueness ?

Coinbase transaction is consensus to the last byte

coinbase tx is not even sent over the network, nodes restore it locally and then check keccak hash, PoW and so on. And check coinbase tx again just in case

merging is part of consensus, it's done deterministically - wallets are sorted and then duplicates are merged

That seems eerily similar to my "game tick" txes in my game. I regenerate them, and was thinking of omitting them from the actual network packet.

omitting them is kind of necessity with p2pool. Coinbase tx can get quite large

Looks like my coinbases have stopped increasing in amount now.

I guess we've reached 2160 blocks since I started.

they should be equal (approximately) to your hashrate divided by network diff

*by network hashrate

multiplied by block reward

*divided by p2pool diff

Handwavy close enough.

Oh, p2pool diff...

there are always luck variations if the number of your shares in PPLNS window is low

yes, for my dev PC it's 963/1404*2.083862640504 = ~1.4293 XMR

Spot on using p2pool hsah rate.

and it got last payout of 1.369020903033 XMR

first p2pool block with transactions in it: testnet.xmrchain.net/block/1794242

good that merkle tree calculation works properly

Also confirmed that it's possible to move mined funds

sweep_all transaction: testnet.xmrchain.net/tx/136025f6431…185153a8250d19a0081642111755c4e311d

that's what p2pool miners would do eventually

looking good so far, 1 second block time works: paste.debian.net/hidden/1fe179ea

ufff. syncing fresh testnet node

estimated 1.2 days left

mine synced in 5-6 hours

testnet has no checkpoints

anyone got a block export of it I could download?

can I do an export on live blockchain? I don't want to stop my node right now

yes, no problems with that

ok, what's the command?

monero-blockchain-export --testnet

should be all you need

oh, I forgot. I don't have a web server there

so I don't know how you would download it...

phooey

installed nginx, let's see what I can do

cool. was syncing from my rockpro64, now \I'm on my ryzen laptop should go faster anyway

4.6 hours estimated

hyc 148.251.81.38/blockchain.raw

thanks, got it

ok I'm all connected

p2pool dies a lot\

"Killed"

how much ram do you have?

prob out of RAM on this box since my regular node is here

4GB

try light mode

--light-mode in command line

ok

so, 25 hashes accepted so far

you're probably still syncing

I don't see 4 wallets in PPLNS window yet

oh, p2pool needs to sync still?

you'll see difficulty jump in xmrig, from 999 to ~1400 when your p2pool node reorgs

ok

still 999 for now

right now you're mining on your own chain from height 0 and p2pool is syncing in the meantime

give it 5-10 minutes

ok

p2pool logging is massive

yes, as intended

it'll get better after it's synced

cool

if you want you can try to set up logrotate to deal with logs

this isn't using easylogger huh, won't rotate by itself?

what block heights do you see in the log right now? It'll stop syncing when you get down to ~36900

no it won't rotate by itself

but it'll detect if you rename p2pool.log

ok

37124

getting there

oh I see you synced

got a bunch of blocks from you that you've been mining

ah there we are

from height 0, so my node discarded them

I stopped the miner in the meantime. just restarted now

I see 4 wallets in PPLNS window now

looks like you're in!

cool!

so the monerod and p2pool are running on my rockpro64

the miner is on my M1 mac

rockpro64 is ARM, right? Nice to test it there too

yes

rockchip RK3399, pair of Cortex A73 plus some A53

looks like my dev PC connected to you, I have 2 outgoing connections now

cortex A72, oops

yeah, nice that my fibre ISP gives me an actual routable IPv4 address

you butchered p2pool luck :D Still no block since you joind

doh

I've been suspicious of the M1 for a while. been solo mining for months and got nothing

but if it were generating invalid hashes we'd see errmsgs right?

yes

I don't see any verification errors, so my node accepts your shares

cool

finally

the fact that this machine miscompiles my simple database benchmarking tool inspires no confidence

already 0.031080440002 XMR? What hashrate are you mining at?

283H/s

oh

you probably mined a lot of shares because we waited so long for a block

wallet shows .06xxx

ah, so 0.03... was mooo's

you should be getting ~0.35 XMR per block with current hashrates after your shares fill PPLNS window

in 30-40 minutes

I've been stopping/restarting mining a couple times when I needed oomph on a dev vm.

gonna spin up a thread on the rockpro64

stopping/restarting should work fine

in a while. recompiling xmrig now

hyc do you have enough RAM there to spin up xmrig too?

will find out ;)

if your node dies, you'll have to sync again

p2pool doesn't save blockchain

? oh

by design

it's ephemeral, old blocks are pruned

ok

of course I can add saving, but saved data gets obsolete pretty quickly

prob not worth it then

saved blockchain is useless after ~6 hours with normal 10-second block time

unless you save in a circular buffer

that might be nice

it's probably needed anyway for the cases when you just need to restart p2pool node

and don't want to sync again

"Monero p2pool. Spent a week syncing the chain ? Sync you're done ? Sync again."

lol

4320 blocks can by up to 200-300 MB of data, depending on how many miners are on the pool

*can be

because initial sync doesn't use pruned blocks

another thing on my todo list :D

BTW, earlier, p2pool crashed on startup with unable to bind. I must have run it once before and it was in wait.

I did not have a stack trace in gdb sadly.

./p2pool --version ends in a crash

lol

it doesn't even have this command line parameter, but it shouldn't crash

Hi! Excited about monero p2pool

sech1: wait

it's not a crash I think, just SIGABRT

didn't look properly

looks like I only have 235M free RAM, won't bother starting xmrig there

going to move monerod and p2pool to the mac

also don't forget to look at p2pool memory usage. It shouldn't be leaking memory. My node has been stable at 3469620/37780/10096 (VIRT/RES/SHR)

p2pool doesn't want to run on mac

I get an abort. haven't got a backtrace yet

starting under debugger gets an immediate abort, pthread_kill inside uv_rwlock_tryrdlock

2.6 GB resident. Looks like I did not take out the full mem after all.

hyc: does ./p2pool --help work?

without abort

Oh look, it's got a --light-mode. Should have looked before grepping and chaning...

I just ran ./p2pool --help here, I got the help, but it doesn't exit.

Ctrl+C

yes --help worked

without debugger, it starts and runs for a while before it aborts

there is a thread reading from stdin waiting for console command and it stops p2pool from exiting properly unless you press Ctrl+C

no need for ctrl+c on mac with --help

there don't appear to be any legal console commands

Stack in PM.

hyc: same here

Possibly ir crashes before the hang on mac :D

hyc p2pool has a few console commands, check console_commands.cpp

I don't have xmrig and monerod testnet setup here so can't fully test it

think I'll write a PR to add a help and exit cmd

though I guess EOF is fine

sure

BLOCK FOUND ooo

I'm working on the block cache (circular buffer as you suggested)

BLOCK FOUND is printed every time p2pool finds a block, not just your node

ah

because it will be rare thing on the mainnet

you'll see "submit_block: BLOCK_ACCEPTED at height ..." log message in addition to that if your node finds a block

it all scrolls by too uick to notice

you can grep the log

and the release will have more shy log level by default :)

will monerod overwrite my mainnet blockchain if i run a testnet ?

No.

What's up everyone. Is this channel exclusive to the p2pool project?

nope. all things monero-proof-of-work

Gotcha. Looks like I'm a little early to the pool party then.. hehe

well, p2pool is the topic du hour

du jour*

someone is fighting ETH for high fees? xmrchain.net/block/a48494d5cc4239d2…f74a75b34910f210eca79f33c0023203e09

0_o

2.9 xmr for the fee? what wallet implementation even allows that?

I can never get a clean exit, stratumserver hangs in destructor on uv_thread_join

sorry, 2.04 .

its lopp is still in uv_run even though uv_stop was called

p2pool, zmqreader, and p2pserver loops all stop/close cleanly

hyc I have the same problem in Linux, but it shuts down fine in Windows. It looks like it just doesn't close TCP sockets

sounds like a libuv bug then

yes, I remember that it got stuck even without xmrig connected. It couldn't close listen sockets

I've been experimenting with saving/loading pool blocks on startup and found out that initial sync is very fragile and depends on the order in which blocks are received

not sure how to make it robust, a bit of refactoring will be required

I was thinking it mainly got stuck when there are no miners connected, since that's my current tester

i just saw the pull request for the p2pool project you could avoid all the const char*, char[] etc when using std::string_view, the pull request literaly deploys its own string_view as a struct called strconst

all the static constexpr char[] = ... globals could be changed to be static constexpr auto bla = "someString"_sv

ofc the auto can be avoided if the author of the projects does not like auto

auto makes some things unnecessarily obscure, particularly when reading source code while debugging

yeah thats why i said the auto ofc is optional :D i code a lot of scala normaly which is why i dont care not seeing the type :D

it's a perfect example of C++ making irrelevant things easier up front and even harder later on

i use auto all the time and i have never got into problems using it, i guess its personal perference

i hate typing types, the compile knows exactly which type an expression has, why should i need to be forced to write it all the time?

debugging is usually an order of magnitude harder than writing code in the first place. so features like that are optimizing the wrong thing

auto does not make debugging much harder?

it either typchecks or it doesnt

that's not the point

i dont know what obscure useage of auto you are refering to which makes debugging harder

when you're trying to find a bug and you want to know sizeof(foo) or what fields are present etc

it's better when it's all explicitly spelled out in the source code

instead of you needing to invoke helpers to decipher it for you

typechecking isn't the issue, and again, it's trivial to do that up front

we call them efficiency elves

but when you're deep in the weeds, all of that abstraction just hides details you might need to know

i guess thats your opinion and i only see that argument made for c++, almost all modern languages support typeinference and nobody has the debugging problems

hyc I'll merge it tomorrow but I can already tell it won't compile on Windows because of "kill" call

sech1: yes, that's why I said it needs feedback...

but as i said i usually do scala or haskel so i am used to not writing types :D

almost all modern languages besides C and C++ are interpreted so they're really not worth discussing here

rust, scala, haskell ... non of that is interpreted

scala is a jvm language

yes?

never mind. this isn't the place for language debate\

you are right :D

sech1: couldn't figure out why calling uv_stop(uv_default_loop()) from do_exit doesn't work, but it works from the signal handler

hm. it does work, but takes ~20 seconds to happen

They really should have made auto mean "do what I mean". Like, int process_data() { auto; }

Now that'd be somehting worth having.

;)

hm, took 2 minutes that time. talk about flaky. why do people like libuv, again? looks like crap, to me.

basically it seems that uv_run sits in an epoll_wait() for a bunch of descriptors, which are usually network sockets

but if there's no network activity, it never wakes up for local things like uv_stop()

one would think they'd be smart enough to add a pipe in there for local event signaling

ok, so the workaround would be to just connect and immediately disconnect

that would wake up epoll_wait

and do it in shutdown_tcp()

libuv is hard to handle, but it wraps the most efficient network layers in each OS

do i have to have the ports open in my firewall for p2pool to work ?

it's not required, but it will work better with open ports

i'm sending shares and getting tx in the wallet, all good

nice

aha, figured out how to make sure the event loop wakes up immediately