11:19:07 https://www.reddit.com/r/Monero/comments/p9apyd/psa_monero_decentralized_mining_pool_p2pool/ 11:33:42 good post 17:12:29 Hey everyone 17:14:59 i checked out the p2pool project an here https://github.com/SChernykh/p2pool/blob/510b7dbb857ee7c6d1ba94933136560d82f581cb/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 17:15:00 reinterpret_cast the result is the same and nothing else. my guess is that a simple static_cast in this situation would be better 17:15:07 https://stackoverflow.com/questions/573294/when-to-use-reinterpret-cast for reference 17:16:50 nonce is uint32_t, only reinterpret_cast works there. I could of course split it into bytes first to make it "properly" 17:17:31 It won't work on little endian machines, but I only support x64 (which is big endian) for now 17:18:11 damn, I mixed it up again 17:18:19 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 17:18:21 nothing else 17:18:22 x64 is little endian, big-endian is not supported 17:18:48 and since we are using the result of the reinterpet cast with the + operator this could be UB 17:20:03 https://en.cppreference.com/w/cpp/language/reinterpret_cast 17:20:20 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. 17:21:09 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 17:23:03 64-bit ARM should also work fine with these 17:23:31 what is this code trying to do? write a sequence of 8byte uints into the vector? 17:24:21 yes 17:24:49 ah i see :D 17:24:51 the proper way would be to write "nonce & 0xFF", then "(nonce >> 8) & 0xFF" and so on 17:24:58 another question about the project. it currently uses C++14, are there any plans on supporting a newer standard? C++17 or C++20? 17:25:05 i am much more familiar with C++17/20(which ofc is not a reason to update) :D 17:25:12 shouldnt static_cast work, too in this situation? 17:25:17 UkoeHB yes writing the 4x 8bytes of an uint32_t into a std:vec 17:25:20 If C++17/20 has something that can dramatically reduce code complexity then why not 17:26:29 error: invalid 'static_cast' from type 'uint32_t*' {aka 'unsigned int*'} to type 'uint8_t*' {aka 'unsigned char*'} 17:26:36 so reinterpret_cast it is 17:28:13 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 17:28:46 that could eliminate all uses of raw arrays by using std::array 17:30:09 C++20 adds a lot constexpr algorithms 17:30:11 https://github.com/SChernykh/p2pool/blob/510b7dbb857ee7c6d1ba94933136560d82f581cb/src/wallet.cpp#L61 17:30:31 this for example could be a single constexpr call to std::reverse on the std::array holding the alphabet 17:31:31 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 17:31:40 C++11 didn't let me do ReverseAlphabet constexpr 17:33:38 i understand this approach, but C++17 is already 4 years old and compiler support is quite well :D 17:34:16 std::string_view(C++17) and std::span (C++17) are also super handy i think 17:34:38 Maybe later, after the release. I have quite a few features still not implemented 17:34:48 like automatic peer discovery and TLS support 17:35:36 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 17:36:04 Monero uses seed nodes to solve this, I'm thinking about a bit different approach 17:36:35 what approach are you thinking abut? 17:36:38 about* 17:37:29 leeching off bittorrent's DHT network :D 17:38:15 isnt that just like a seednode with extre steps? 17:38:45 yes, but it already has millions of peers, so it's much more robust 17:39:09 plus I don't want to run any server to support p2pool, even if it's just a seednode 17:39:19 the idea is to be 100% serverless 19:41:12 sech1 would a low-hashrate miner be able to earn enough to outpace tx fees from combining all the outputs he receives? 19:42:39 1in/2out transaction is ~1455 bytes on average and has a fee of ~9 micronero. Minimal payout would be ~0.0004 XMR (400 micronero) 19:43:14 So even simply moving minimal payout is possible and fee would take ~2.5% of the payout 19:43:44 combining multiple inputs reduces this percentage significantly because resulting transaction gets smaller (per input) 19:44:16 I see, ok 19:49:16 couldnt this be a problem for some persons since some ISPs are blocking bittorrent traffic? 19:51:03 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 19:51:42 I'll probably start with seed nodes because it's easier to implement 19:51:58 sounds nice :D 19:52:55 wouldnt every conglomerate of miners use their own blockchain and therefore needs to provide their own seednodes? or am i getting this wrong? 19:53:30 if i and x other friends decide we want to mine together wouldnt we need our own blockchain with our own seednodes? 19:54:55 seednodes can keep peer lists from multiple blockchains 19:55:11 peers will just send blockchain id and receive the corresponding peer list 19:55:46 that sounds an awful lot like torrent trackers, I know :D 19:56:00 I was heavy into bittorent development in the early 2000's 19:58:17 i see, that sounds like a nice project 20:00:20 another question regarding the project. why are the dependencies are not in there as git submodules? 20:00:56 is there any reason? because if they would be git submodules, i guess updating them would be much easier 20:01:31 because it wasn't a git repository until today, lol 20:01:42 I'll change it eventually 20:04:23 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? 20:07:17 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? 20:08:01 sd::array is only in one place 20:08:30 I think that came from wallet.cpp that I wrote for xmrig initially 20:08:59 ah ok makes sense 20:12:52 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 20:13:41 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 20:14:03 in the end it is you project :D you decide 20:20:59 I don't even remember why I made m_poolBlockTemplate a pointer at all :D 20:21:23 Yes, lots of refactoring can be done, but I prefer to have a working project first 20:23:18 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 20:24:00 yes, refactoring to get rid of raw pointers would be sweet, but I need to make a 1.0 release first 21:00:56 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 21:01:16 https://www.reddit.com/r/Monero/comments/p9apyd/psa_monero_decentralized_mining_pool_p2pool/h9xx2v9/ 21:03:05 I don't see any ops here right now 21:07:31 me neither, someone will need to be opped to reply "yes" to a DM 23:02:48 hmm. gonna have to look into getting sech1 & me op'd in this channel 23:03:05 but certainly taking down the freenode bridge should've been done long ago