Are there any projects which integrate pool mining directly into their protocol?

<sech1> "monerod is a more appropriate..." <- I actually really like this idea. It makes it vastly easier for anyone to develop a UI whereas a bunch of effort to add it into the GUI only gives us one implementation.

So add to monerod first, then add to GUI via monerod

add what, to monerod? a miner that can mine against p2pool?

no, add p2pool itself, so that it can be easily launched even by non-technical users

> <@rucknium:monero.social> And there is now a 25 XMR bounty for writing code integrating p2pool into the Monero GUI wallet. Any takers?

> bounties.monero.social/posts/53/int…2pool-mining-into-monero-gui-wallet

Thanks. My current proposal wears off at the end of January. If there are no takers until then, I could handle it.

But if there are: just go ahead.

Nice.

Ah. There's already a PR :)

mj-xmr I'm not taking that bounty, but I can add more stuff to p2pool code to make integration easier

Good point by selsta. monero-project/monero-gui #3829#issuecomment-1018191461

That's nice. Let's talk in Feb. Perhaps this bounty is no more by that time anyway.

I have a mad idea. Allow aggregate PoW so that any miner, however small, has a chance to contribute and get rewarded straight from the chain.

Suppose we allowed up to 32 proofs of work to be associated with a block. Such that the sum of the work met the target toughness.

I do not believe this would substabtially increase block size. But it would increase block time reliability.

The reward structure could be such that there is no relative benefit to making a smaller contribution to keep miners preferring one size over another.

In the simplest case, imagine two miners that have found nonces that are just short of the target. These two PoWs could both be associated with the block. The block is published as enough work has been done.

How would you distribute the block reward though? Those 32 proofs are not going to be found at the same time. How would you prevent a faster miner from witholding a block until they've found all 32 proofs for themselves?

Also, pow hashes are not additive (at least as far as I know?)

To your second point, I dont think we should care. If someone has done the work then so be it. But will they be faster than cooperative miners....probably not.

wernervasquez[m]: Each miner is working on a different block template though, and they would have to somehow share results in real time to know that both of them have found a nonce "close enough" to the final target

regarding the additive nature of hashes, we would only be summing some abstract notion of work such that the total represents a given target.

Regarding distribution, I have been thinking. Why do miners include the amount of their own reward if literally everyone verifies that it is correct anyway.

given a set of workers which have done some work and to choose the right ones to meet a given target sounds a lot like the knappsack problem.

atomfried[m]: nevermind ... ofc it is ok for them to overshoot the target of required work

We only need to check that they spend the correct amount when they cash it in. Why do the work twice?

no i meant from the perspective of the miner it could be not that trivial to find and select the other shares.

So, I think we could establish a reward splitting algo that establishes how much each miner should be able to spend against a block they helped mine without including the amounts with the block explicitly.

maybe this could lead to some kind of central mining server collecting all the shares and doing the work of collecting them together

So, a miner finds a partial PoW and puts the block and proof in pool like the tx pool

wernervasquez[m]: They "cash in" the reward the moment they publish the block, via the coinbase transaction

Any other miner could start working on that block if they so chose.

merope: suppose a miner mines a block and publishes his address but no reward amount. Later he spends the amount he should have received. The protocol finds the block he is spending against, calculates his reward, allows the tx if it verifies.

Same if someone uses it as a decoy.

Why calculate and publish in the chain a quantity which everyone both has the ability to calculate and already does so to check its validity

wernervasquez: Xthinner from BCH is maybe relevant:

wernervasquez[m]: Because it changes the hash of the coinbase tx, and thus the whole block hash

If the kinks of such a proposal could be worked out, theoretically , even the weakest individual miner could contribute to a block if they push the sum over the target.

merope: Why include a value in the hash which everyone can calculate on their own?

wernervasquez[m]: what are you attempting to save?

the value isn't there by itself. the coinbase txn amount includes both the emission and sum of txn fees

removing the emission value doesn't save any space, the coinbase txn still needs to be there

Because without the inclusion of the coinbase tx in the merkle root, anyone could rewrite the coinbase tx and steal the reward

anyway, this overall proposal doesn't seem to offer any advantage over p2pool, while severely weakening a lot of integrity guarantees

hyc: just brainstorming an idea, no need to shoot it down a priori just because it's incomplete

merope: Let me make sure I understand. Currently, does a miner include both his address and his reward in a block and thus its hash?

If so, why not just include the address? What does putting the amount in accomplish?

Not the address per se, but yes

merope: better not to waste time on obviously bad ideas.

> <@rucknium:monero.social> wernervasquez: Xthinner from BCH is maybe relevant:

> news.bitcoin.com/xthinner-protocol-…-mainnet-shows-99-block-compression

does monero have something like xthinner currently?Rucknium

well, the output publickey or whatever the technical term is

hyc: then don't chime in if you have nothing to contribute :)

merope: saving time is a contribution.

and people who don't know wtf they're talking about aren't actually contributing anything

hyc: Tell me how you really feel :P

atomfried: I don't know. I don't think so. Someone else would know.

wernervasquez[m]: if you're asking about what is contained in the coinbase txn, then you should have done your homework before suggesting changes

only fools try to change a system before they understand how it currently works

Good learning opportunity though. And who knows, maybe they might come up with something new

hyc: Do you have a specific criticism which I can take back to the drawing board?

a good learning opportunity requires doing the homework first.

\as I already said - you're not saving any space by removing the emission value. so what do you actually hope to accomplish?

hyc: It is not foolish to ask questions, which is what I have done. Not making a PR here...

also you make it more difficult to analyze individual blocks. i.e., given a block ID, we need only inspect that block to see its coins.

with your proposal, any time anyone wants to inspect one block, they must always do a complete sume from block 0 to that block ID to know what the expected emission amount is

again, my words were quite specific. it is foolish to *suggest changes* to a system before you understand how it currently works.

asking questions is one thing. but you're going beyond that.\

Jesus christ...

so - what do you hope to gain, for all of the cost you'll impose on how the blockchain gets used?

hyc: I respect you a lot and think you are very smart. I can handle your blunt dismissiveness. But you may turn away others who could grow into something with such coarseness.

+1

if you really believe it's too much to ask that everyone participating in a reseaarch discussion already understand how things currently work, then I have bad news for you

that's now how anybody gets work done.

You know, some people learn more by asking questions about stuff they don't know to people who do know

s/now/not/

And if your time is too precious to answer them, then nobody stops you from not replying (thus saving more of your valuable time)

hyc: I like you. Chatting in a quiet channel, on topic, is not a problem.

merope: this is not a question: (09:07:13) wernervasquez[m]: So, I think we could establish a reward splitting algo that establishes how much each miner should be ab

le to spend against a block they helped mine without including the amounts with the block explicitly.

hyc: I really do respect you and intellect.

hyc: You have provided me with at least one, thoughtful, specifc point to ponder. Which I will go and do.

there's plenty more. miners aren't required to use the entire block emission in the block they mine.

i.e., the emission per block isn't actually a fixed/predetermined value.

a miner can choose to underpay themself, and then a future block can include the unspent excess

they could before, but now they're forced to get the full block reward

Not anymore

8:23 AM <hyc> merope: saving time is a contribution.

Speak for yourself... wtf is this patronizing thing?

still haven't explained what they hoped to gain.

and why it's better than just using p2pool

Someone types a little wall text with an idea, couple questions, in a research channel and they get mauled by another wall text of patronizing, abrasive, shut-it-down comebacks.

"I have a mad idea. Allow aggregate PoW so that any miner, however small, has a chance to contribute and get rewarded straight from the chain."

4 people call you out and you keep doubling down on it?

Really?

That was the initial premise

p2pool already rewards miners straight from the chain

Sorry a genuine proposal, or rather question, upsets you so much.

But p2pool still follows the "traditional" pow method, where a single hash above the target wins, and all other hashes are wasted

wernervasquez's idea is that multiple below-target hashes could be aggregated in some way to find a block

they're not wasted. shares are accumulated and determine proportion of payout

1 - that's a p2pool-specific thing

2 - p2pool itself, under the hood, still follows that method

Oooooh

yes that's a p2pool-specific thing, but it already exists and works

and doesn't have an arbitrary 32-payee limit

But p2pool is still based on the premise of pool mining

I don't see the relevance of that comment

miners form their own blocks

What if each miner can individually combine their own hashes (without sharing them with others), and use the combined work to claim a block? This could significantly reduce the effect of variance, which combined with the nonce-signing proposal would make solo-mining slightly more tolerable to small miners

^ see? Research questions!

... and how will they do that?

gee, maybe they will pool their work so they can tally up how close to the target they've gotten

If the diff is 100 and I find two shares worth 50, they go to waste in the current system

imo the combination of the work of the single miners would again be solved by a centraliced mining pool which then would just give more power to them.

^ exactly

But with a "cumulative pow" I could submit those two shares to claim a blocm

atomfried: hence the second part: combining the cumulative work with the nonce signing (which forces solo mining)

<hyc> "with your proposal, any time..." <- Doesnt everyone already recalculate the miner reward to accept the block? Why does it matter if that calculation is done at the time of block publishing, or at the time of reward spending? Worst case, anyone who cares calculates the reward at the time the block is mined and store it in an off chain database for future reference.

(Doesn't completely fix the issue of leaving small miners at a disadvantage, but it's less bad)

merope: would then the monero nodes perform the combination to a full block? what happens if two nodes with different shares of small miners combine a different block from different work pieces

atomfried[m]: What happens if two nodes choose competing blocks now?

highest pow wins

but you're introducing a new pool that nodes must maintain, in addition to current txpool

p2pool does the same work, but tracks it on its own sidechain that monerod doesn't need to worry about

atomfried[m]: Instead of verifying a single nonce and checking against target, it would verify both my nonces and check that their sum meets target. Still subject to the rule of highest cumulative pow

whatever you do will require new bookkeeping

No new pool in my idea. Instead of having a single nonce in the block header, a miner can optionally include up to N (where N is limited by the protocol)

So the only extra recordkeeping would be a few extra bytes for each additional 32-bit nonce

so for an incoming block all nodes will have to perform N pow verifications instead of just 1

Yes, as I've already mentioned

that seems like an anti-scalability feature

But I suspect even N=2 or N=4 would have a pretty significant improvement on variance

And if I'm not mistaken, pow verification is only a small part of block verification. Checking the validity of all txes takes longer (and the bigger the blocks, the more prevalent tx verification becomes)

merope: could nonce signing lead to custodian mining pools where they pre sign a huge number nonces with their key and the miners need to use only those?

atomfried[m]: I think you're the first one to ask that question...

merope: i guess thats a bad thing ...

But I don't think it would, because the pool would have to redo all the signatures for each new block header (ie a new block, or a tx gets added to the current block)

Which would require pretty significant computational resources

(I think I read a comment somewhere about the potential asics for that signing part?)

ah ok so not only the nonce is signed but also the new block header

From what I recall, yes

tbh i just heard about this nonce signing thing about half an hour ago, so i have not fully understand or reasearched it

that's what wownero is doing now?

Yes: git.wownero.com/wownero/wownero/pulls/369

the pr is closed or am i wrong?

it's been in effect for a while

ah ok

aggregate pow requires all shares to be checked during block validation, this is too slow

RandomX validation takes 0.01 seconds already

yeah, this proposal will make for easy DOS attacks

<merope> "No new pool in my idea. Instead..." <- I think that is a better idea than what I was thinking. It is a much simpler change which retains the benefit of reduced variance.

Would taking 0.02 or 0.04 seconds be so bad, relative to the benefit of decreased miner variance?

Re: DOS attacks - if a node gets caught sending "too many" invalid blocks, it gets banned

And the "too many" threshold can be tuned to be N out of the last M blocks, such that even a large swarm of malicious nodes could only add, say, less than 10% extra work for the whole network overall

p2pool gives decreased miner variance, by the factor of 500x and it doesn't burden block validation for the rest of time (every syncing node will have to verify all PoW shares)

this proposal would kick all pi nodes off the network.

I remember we had to reduce RandomX dataset size from 4 GB to 2 GB just because of this (validation time)

Yes, the nonce signing proposal (as implemented by wownero) is very bad for small miners - I already delved into that yesterday

<sech1> "p2pool gives decreased miner..." <- Is a further decrease not beneficial? p2pool would lower the variance even more leveraging such a change.

p2pool is configurable, it can lower the variance even more but then individual payouts would be too little (network fees would eat a significant % when moving mined coins)

new node operators would not thank you for increasing validation cost

right now network fee is ~0.8% when you move a single smallest p2pool payout

hyc: Obviously a concern, but what is your personal threshold when you stop worrying about old hardware. sbc's get faster like everything else.

I'm already assuming hardware advances. it's not about old hardware.

it's about ubiquitous hardware. whatever the lowest threshold is 5-10 years from now should not be a smaller set than it is today.

Of course it's a tradeoff. We are trying to establish if it's a worthwhile one

(And possibly quantify that)

Perhaps it could be tested on wownero, and see the effects that it hash on nethash?

Our diagnosis of the problem is: It's too easy for noob miners to point xmrig to the first Google result for a pool (minexmr)? About to give a controversial and maybe unworkable idea...

prepares popcorn

It feel like some of these proposals are dealing with the problem in a quite indirect way. Instead, maybe xmrig devs issue an ultimatum to minexmr: temporarily increase your fee (which would reduce number of miners) or the new compiled versions of xmrig don't allow mining to your domain.

a bit draconian

a better idea would be for xmrig to poll a list of pools e.g. from miningpoolstats and ping them

then choose the one with the lowest hashrate and fastest ping time

or if not lowest hashrate, <moderate> hashrate, excluding the highest.

But then you'd be relying on whatever centralized resources provides the nethash numbers to be true

Maybe not outright stop miners, but it should spam a big letter warning to move to smaller pools

The problem is that minexmr has a lot of (pre-existing) botnets

I somehow pity minexmr: You put up a top-quality mining pool, always serve your "customers" well, be stable and trustworthy, and so on, and as a "thank you" the community ponders nuclear options like this ...

And botnets don't give a fuck

at least 1/3 of their hashrate are a few big botnets

minexmr just needs to ban they so they'd move elsewhere

And neither does the minexmr admin very much

Rucknium[m]1: I think things like nicehash or Norton antivirus cryptominer that may have default/hardcoded pools are a bigger and more likely problem than people googling pools and finding minexmr.

norton is relatively new, and only on eth

Bigger problem**

Isn't it possible for there to be an independent measurement of pool hashpower by mining to a bunch of pools and observing payouts to your miner?

Yes, but it's just a matter of time and very likely that some corporate bobble head finds out ASIC resistant algos are a thing and plops a minexmr in the app

... we can setup another sidechain where miners report their observed hashrates

rbrunner: minexmr knew what the game was when they entered. Get too much hashpower on a PoW coin, and a target forms on your back.

pools even DDoSed each other in the early days

Rucknium[m]1: Iirc moneroocean does that. Or maybe some other pool, don't recall

any big botnet miner can ddos minexmr to boost their profits for a while

There's a page somewhere which lists the income vs expected income on a bunch of different pools, using a few small workers

But still, it's a centralized resource

right, so use a blockchain instead. a sidechain...

although not even sure that's needed.

pool blocks are all identifiable, so a miner just has to read the last N blocks of the mainchain and see which pools are dominant

Rucknium[m]1: Sure. Something like a business that works so well as to achieve a monopoly and then getting shot down by corresponding laws. Still a little paradoxical, punished for being too good, right?

monopoly is not good

especially in blockchain :D

rbrunner: twitter.com/hyc_symas/status/1316389016959438855

Lol

how would a pool info blockchain work... have all miners broadcast the domain/ip addr of the pool they're using, sum the counts up into blocks?

decentralizing the ledger is easy enough. how do you validate it? what's a possible proof-of-pool algorithm?

hyc: but then Monero would be a public utility, because it's >80% of private cryptocurrency transactions worldwide :-P

lol

but we're not a corporation

are we sure new miners are actually googling to find a pool to join? why not just hardcode xmrig to default to pointing at p2pool in the first place

because you need a synced blockchain

wallets already know how to find public nodes

hmmm

And a running p2pool

starting p2pool up from scratch only takes some tens of seconds

And yes, lots of miners just join the first pool they find. Plus a lot of incomplete or outright bad info, so many end up joining minexmr because it sits at the top of the pool list

I've encountered multiple people that thought bigger pool == better

Once you know the startup flags, sure

big pools = less variance which actually matters with a decreasing block reward

does using p2pool requires running a full p2pool node or could there be an electrum equivalent for p2pool?

But non-technical users who barely know what a wallet is have a very steep learning curve when they first start

even so, it's easier to wrap the startup procedure than design all this other stuff

atomfried: you have to pass your wallet address as a parameter when starting p2pool

And that p2pool instance will only mine for you

Hence the cureent 25 XMR bounty to integrate p2pool into the official software

so. newbie installs GUI wallet. wallet selects a public node automatically

nioc: the decreasing block reward affects everyone the same way though, regardless of the pool size

wallet now has a public node address and a wallet address, which is sufficient info to give to p2pool

Doesn't p2pool requre unrestricted rpc access though?

no

it only does if you want it to use monerod for pow validation

For when p2pool asks for a block template

which only makes sense when you're running monerod on same box as p2pool

no, that's a public rpc

merope: not as much now as the the block reward decreases very slowly now, someone did the math about a year and a half ago and it did make a difference

final steps: short xmrig benchmark run to get baseline hashrate. then start xmrig with fixed difficulty based on hashrate, so that p2pool gives meaningful statistics

the latter might usefully be combined into one step in xmrig code itself

depends on the difference between the pools, I was on one that found a block every month on avg

i'm not sure the aggregate pow idea is actually beneficial. consider a small network with 2 miners. 1 has 1H/s and the other has 2H/s, and difficulty=4.

while the smaller miner on its own would solve the PoW in the target time every time, the faster miner will usually solve it in one half of the target time

forcing the difficulty to adjust higher, and basically locking the slower miner out from ever finding a solution

basically, allowing an aggregate of N=2 pow hashes makes a faster miner's advantage over slower miners quadratic instead of linear

and the advantage gets even greater with larger N

so while you're trying to make mining results better for slower miners, you're actually killing them

The small miner still has roughly 25% chances of finding a valid hash in a single try, and some good chances of finding the result in two hashes (1+3, 2+2, 3+1)

minexmr didn't go from 37% to 42% to 37% because of noobs mining to the biggest pool methinks

yes, they have several 100+ MH/s miners

merope: the faster miner has even more chances though. more than 2x.

obvi just need to stop all the botnets

<UkoeHB> "I have seen wernervasquez and dr..." <- I do have a mathematical background and a keen interest in protocol details but admittedly limited coding experience. I do happen to have quite a bit time right now, though. Perhaps I could be help