good post

Hey everyone

i checked out the p2pool project an here github.com/SChernykh/p2pool/blob/51…60d82f581cb/src/pool_block.cpp#L140 it uses an reinterpret_cast to cast from a uint32_t* to a uint8_t*, i think using this pointer after the cast is UB because the only thing the c++ standard guarantees is that when casting back with a

reinterpret_cast the result is the same and nothing else. my guess is that a simple static_cast in this situation would be better

stackoverflow.com/questions/573294/when-to-use-reinterpret-cast for reference

nonce is uint32_t, only reinterpret_cast works there. I could of course split it into bytes first to make it "properly"

It won't work on little endian machines, but I only support x64 (which is big endian) for now

damn, I mixed it up again

are you sure about that? reinterpret_cast only guarantees that if you cast a pointer to a different type, and then reinterpret_cast it back to the original type, you get the original value

nothing else

x64 is little endian, big-endian is not supported

and since we are using the result of the reinterpet cast with the + operator this could be UB

the behavior is undefined unless one of the following is true: AliasedType is std::byte (since C++17), char, or unsigned char: this permits examination of the object representation of any object as an array of bytes.

I do have quite a few reinterpret_casts there, but I understand quite well what they do on x86. Porting to other architectures will require rewriting these parts

64-bit ARM should also work fine with these

what is this code trying to do? write a sequence of 8byte uints into the vector?

yes

ah i see :D

the proper way would be to write "nonce & 0xFF", then "(nonce >> 8) & 0xFF" and so on

another question about the project. it currently uses C++14, are there any plans on supporting a newer standard? C++17 or C++20?

i am much more familiar with C++17/20(which ofc is not a reason to update) :D

shouldnt static_cast work, too in this situation?

UkoeHB yes writing the 4x 8bytes of an uint32_t into a std:vec<uint8_t>

If C++17/20 has something that can dramatically reduce code complexity then why not

error: invalid 'static_cast' from type 'uint32_t*' {aka 'unsigned int*'} to type 'uint8_t*' {aka 'unsigned char*'}

so reinterpret_cast it is

C++17 adds for example CTAD a lot of times you are doing something like constexpr uin32_t[] = {...} with CADT you could write for example constexpr std::array = {...} without writing the template arguments of std::array all the times

that could eliminate all uses of raw arrays by using std::array

C++20 adds a lot constexpr algorithms

github.com/SChernykh/p2pool/blob/51…3136560d82f581cb/src/wallet.cpp#L61

this for example could be a single constexpr call to std::reverse on the std::array holding the alphabet

I also didn't want to push for newer standards because of compiler support. I started coding for C++11 and only switched to C++14 because of that specific code

C++11 didn't let me do ReverseAlphabet constexpr

i understand this approach, but C++17 is already 4 years old and compiler support is quite well :D

std::string_view(C++17) and std::span (C++17) are also super handy i think

Maybe later, after the release. I have quite a few features still not implemented

like automatic peer discovery and TLS support

you have to enter at least 1 p2pool peer IP to start syncing. Peers exchange their IPs between each other, but it doesn't start automatically

Monero uses seed nodes to solve this, I'm thinking about a bit different approach

what approach are you thinking abut?

about*

leeching off bittorrent's DHT network :D

isnt that just like a seednode with extre steps?

yes, but it already has millions of peers, so it's much more robust

plus I don't want to run any server to support p2pool, even if it's just a seednode

the idea is to be 100% serverless

sech1 would a low-hashrate miner be able to earn enough to outpace tx fees from combining all the outputs he receives?

1in/2out transaction is ~1455 bytes on average and has a fee of ~9 micronero. Minimal payout would be ~0.0004 XMR (400 micronero)

So even simply moving minimal payout is possible and fee would take ~2.5% of the payout

combining multiple inputs reduces this percentage significantly because resulting transaction gets smaller (per input)

I see, ok

couldnt this be a problem for some persons since some ISPs are blocking bittorrent traffic?

that would only one way to do peer discovery, p2pool can still work without it using saved peer lists. You just need to bootstrap by manually adding peers. Other methods like seed nodes can be added too

I'll probably start with seed nodes because it's easier to implement

sounds nice :D

wouldnt every conglomerate of miners use their own blockchain and therefore needs to provide their own seednodes? or am i getting this wrong?

if i and x other friends decide we want to mine together wouldnt we need our own blockchain with our own seednodes?

seednodes can keep peer lists from multiple blockchains

peers will just send blockchain id and receive the corresponding peer list

that sounds an awful lot like torrent trackers, I know :D

I was heavy into bittorent development in the early 2000's

i see, that sounds like a nice project

another question regarding the project. why are the dependencies are not in there as git submodules?

is there any reason? because if they would be git submodules, i guess updating them would be much easier

because it wasn't a git repository until today, lol

I'll change it eventually

ah i see :D i could add docker files to project such that the compatible monerod node and the pool node can be setup and run using docker-compose are you interested in that?

and another question :D (sorry i am just going through the code a bit currently) is there a reason why you sometimes use raw arrays and sometimes std::array?

sd::array is only in one place

I think that came from wallet.cpp that I wrote for xmrig initially

ah ok makes sense

in the block_template.hpp/.cpp you are using raw pointers with new and delete, you could realy easy avoid all that by using std::unique_ptr i think you could avoid the whole ~BlockTemplate() destructor

i could do such stuff for you so you can focus on adding the new functionality :D i am just checking if you would be ok with such changes

in the end it is you project :D you decide

I don't even remember why I made m_poolBlockTemplate a pointer at all :D

Yes, lots of refactoring can be done, but I prefer to have a working project first

ok perfect :D then i will keep an eye on the project and ping you again once you did a release or add contribution guidlines :D

yes, refactoring to get rid of raw pointers would be sweet, but I need to make a 1.0 release first

I'm going to drop the bridge between matrix and freenode and want to enable a bridge here; is that okay? I'll need an opped person here to approve

I don't see any ops here right now

me neither, someone will need to be opped to reply "yes" to a DM

hmm. gonna have to look into getting sech1 & me op'd in this channel

but certainly taking down the freenode bridge should've been done long ago