Luke-Jr [ARCHIVE] on Nostr: 📅 Original date posted:2013-06-14 📝 Original message:On Friday, June 14, 2013 ...
📅 Original date posted:2013-06-14
📝 Original message:On Friday, June 14, 2013 8:06:54 PM Peter Todd wrote:
> On Mon, Jun 10, 2013 at 09:23:14PM +0000, Luke-Jr wrote:
> > Might as well just use higher difficulty shares (each one audited) for
> > the same effect. Block proposals allow the miner to tell the pool its
> > transaction set once (per txset change) for any number of shares.
>
> That's a good point - the current practice most pools seem to follow of
> about a share per second seems very excessive to me. On the other hand,
> it does have good user optics. The right solution might be something
> akin to P2Pool where the UI level is telling the user shares are being
> found so it's clear "stuff is happening", but under the hood only a
> small subset are ever sent to the pool.
Share rate is relevant to more than user information - it also affects the
variance of reward/payout. I disagree with claiming shares are found when
they're not sent to the pool - this makes auditing and troubleshooting more
difficult; for example, see the GUIMiner bug where it reports shares despite
misinterpreting the pool's target and submitting nothing at all (this happens
when the pool uses pdiff 1).
> > > # Pool work
> > >
> > > So does eliopool already accept arbitrary shares like this and do the
> > > correct accounting already? (IE adjust share amount based on fees?)
> > > What happens when the pool doesn't get the share directly, but does
> > > see the new block?
> > >
> > > + possible protocol extensions
> >
> > I don't follow.
>
> What part don't you follow?
I don't understand the first two questions here at all.
Luke
Published at
2023-06-07 15:03:14Event JSON
{
"id": "c0eab352a6108be470310b99a3d16d8c0e30fc91176c0a9aa0b3f803689168f5",
"pubkey": "6ac6a519b554d8ff726a301e3daec0b489f443793778feccc6ea7a536f7354f1",
"created_at": 1686150194,
"kind": 1,
"tags": [
[
"e",
"c38e7a8da7625c86416fe68c4e70b42114fb544f9c6e041a0fbee015ae13f188",
"",
"root"
],
[
"e",
"1845b29a00772f5d9044606c4966b718579c56a3f2bc3a80c754782f2c54de84",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2013-06-14\n📝 Original message:On Friday, June 14, 2013 8:06:54 PM Peter Todd wrote:\n\u003e On Mon, Jun 10, 2013 at 09:23:14PM +0000, Luke-Jr wrote:\n\u003e \u003e Might as well just use higher difficulty shares (each one audited) for\n\u003e \u003e the same effect. Block proposals allow the miner to tell the pool its\n\u003e \u003e transaction set once (per txset change) for any number of shares.\n\u003e \n\u003e That's a good point - the current practice most pools seem to follow of\n\u003e about a share per second seems very excessive to me. On the other hand,\n\u003e it does have good user optics. The right solution might be something\n\u003e akin to P2Pool where the UI level is telling the user shares are being\n\u003e found so it's clear \"stuff is happening\", but under the hood only a\n\u003e small subset are ever sent to the pool.\n\nShare rate is relevant to more than user information - it also affects the \nvariance of reward/payout. I disagree with claiming shares are found when \nthey're not sent to the pool - this makes auditing and troubleshooting more \ndifficult; for example, see the GUIMiner bug where it reports shares despite \nmisinterpreting the pool's target and submitting nothing at all (this happens \nwhen the pool uses pdiff 1).\n\n\u003e \u003e \u003e # Pool work\n\u003e \u003e \u003e \n\u003e \u003e \u003e So does eliopool already accept arbitrary shares like this and do the\n\u003e \u003e \u003e correct accounting already? (IE adjust share amount based on fees?)\n\u003e \u003e \u003e What happens when the pool doesn't get the share directly, but does\n\u003e \u003e \u003e see the new block?\n\u003e \u003e \u003e \n\u003e \u003e \u003e + possible protocol extensions\n\u003e \u003e \n\u003e \u003e I don't follow.\n\u003e \n\u003e What part don't you follow?\n\nI don't understand the first two questions here at all.\n\nLuke",
"sig": "73333127068da09e2b71b7b680e653c107026ed38dfdcaf31899a803064f823f1be472285dc9f5ffb3a0b251a3a1a06fa99a906808fd081efd0938cb4d37c4f0"
}