This might be in the wrong place (and perhaps a daft idea), but here goes :-
I’ve been thinking about how to get input from miners without giving up control of where block/dev rewards go, had this idea while playing with my stratum server project.
The ZEC nonce is HUGE (256-bits) and the first N-bits (almost all of it) are set by the pool - this could carry a short message without affecting anything.
Its trivial for a pool to encode their answer to a poll/vote/survey in this way & responses could be rich (ie: several yes/no answers, plus checksum etc) with just a few bytes.
The number of ‘votes’ cast by a pool would be proportional to their influence (hashpower)
Polls/votes/surveys could have a start & end block number.
Responses are public, transparent & immutable.
Collects information without affecting revenue/funding streams.
Pools could also open this up to their clients, encoding the miners preferences into work they receive or offering a range of port numbers to mine to.
Its just an idea on voting/polling. There was a comment that we don’t really know much about what miners want or their opinions & thats what got me thinking, we could gather that information without giving them control of funding.
Example, lets pretend we have four choices on a new PoW & want to know what miners think - ask the question & then look at answers encoded in the nonces of the next 5000 blocks.
the mining pools would or could control this, not the average miner at all, hence we would get the opinion of the about ~10 -15 mining pools? If this is the case it would be easier to send them just a survey by email.
IF the average joe miner should participate i have concerns how someone would reach them, even more how they had to modify things on their end and the ability to do it. And even than it would be again up to the mining pools on if they honest forward the miners vote/poll/answers or edit them and/or not accept them and/or at all forward the result.
Just some concerns that came immediatly in my mind. As your idea contains some deeper technical details i may miss something important here.
I was thinking about this too how the miner could choose where to send the dev fee, if the addresses to choose from were coded as result types (or whatever C has, a bool I suppose) where the founders addys are now then this should selectable in the mining software
(If bob chooses addy A, B, C and not E, F, G, then the latter would simply return a false type and the fee distributed across the former)
The percentages should be selectable here as well
Kinda different… for sending fees the pool just creates the outputs they want for the coinbase txn, provided the amounts & addresses match whatever rules its mineable & the funds go to the right pockets.
This is just a way to get information from the miner/pool without using txns (ie: no money).
Edit: Might play with this & make a testnet prototype
Edit: Changed ‘miner’ to ‘pool’ as the pool controls what work the miner gets
one thing tho, does it impact the entire nonce range? it might not be feasible for asic miners to do that, it would have to be done at the pool or protocol level.
just a thought. I don’t own any asic stuff so I cant really comment.
Ok - I’ll let you know when I’ve got something going.
The nonce range is a 32 byte number, big enough to count all the atoms in the known universe (something like that).
I’m going to steal the first four bytes, should be enough for something very basic as a ‘proof of concept’.
The miners use the least significant bytes & cycle through them when looking for solutions - normally they only get a few to play with. When they run out they ask the pool for a new nonce.
All this works at the pool level so ‘should’ work with any miner
ah cool. I think I misunderstood how it will work. I thought the miner would set a flag which would enable a coinbase payout. which actually kinda is what you are suggesting but I didn’t think past solomining and gpu mining. you are suggesting a protocol change.
I like the idea, if it is secure.
true but there are more possible hashes than atoms too. (I will double check the collision resistance to see how many bits you might be able to safely fiddle with.)
You meant first 4 bits right? not bytes? (do you need 32 single binary options? its a massive a mount if you let more than one bit be set.)
I’ll leave the security aspect to ‘smarter minds than mine’ - this is just a simple hack to explore an idea (maybe a bad idea!).
I was thinking a few bytes would be more useful so values (0-100) could be encoded - so one byte per value, plus a checksum byte to separate signal from noise. Lets say four bytes total - that would give three values, three binary options, and a checksum)
ah you did mean bits.
you can do all that with just one byte, or even a nibble if you drop the checksum - but the that’s quite a good idea, because it still allows people to mine that range and not signal. edit2: what is wrong with me today. you are suggesting to use a nibble, with the last bit being the checksum, I think.)
checking the collision resistance (ie if you fix a certain set of input bits, what does that do to the output) is just a couple of equations. I think they are in the whitepaper. haven’t read it for a while. anyway if you stick the hack together I will gpu mine it.
Or if you fix a set number of bits are you limiting the hashes you can output.
if current collision resistence = CR and new resistance = NR then if NR!=CR bad. if NR is lower than the total possible number of hashes/NR then you might miss some blocks. (these are not definitive calculations there is a lot more to it. - its just the basics) - edit: rereading this, it might actually be total rubbish. heh. I need to check the whitepaper.
This is a great idea! It is a complement to the First Coin-Holder’s Straw Poll. Could you please define what bits the miners should set to indicate which of the codenames for NU3 they prefer?
Thought I’d start with something ‘completely daft’ just to see if things work out & play with it on testnet for a while - obviously there are more serious questions we could ask
Its a webwidget that generates the extra bits for a miner login & would appear as the first four bytes of the nonce if that miner finds a block - or a pool could set those bytes for all of their miners.
Edit: Just for grins, I showed version 1 of the poll to my SO, the question was ‘What should ChileBob spend testnet coins on?’ Options were: Beer, Women, Motorcycles…she added ‘Liposuction’ to the list !!!
Testnet blocks after 551169-551180 (mined by me) have ‘c864b34d’ as the most significant four bytes, which match the string I added to the ‘username’ on my miner.
I’ll come up with a ‘read script’ to scan blocks for votes & gather results etc - probably tomorrow.
(Note: ‘getblock’ shows the nonce as little-endian, so read it backwards)
I’ve got the miner sending its four bytes to the pool, blocks are being mined with the modified nonce and a tool to scan for nonces containing votes - but its not quite perfect.
My checksum method is wonky, scanning 5000 blocks revealed 5 voting nonces that shouldn’t be there, so I need a new checksum algo.
Oh…look…a forum full of cryptographers… any ideas ? I have three bytes of data & one byte for a checksum.
I don’t think you can ever get this down to a zero level. - I think they best you can do is to make sure that no vote and hasn’t voted are take care of is the best you can hope for. after all a valid block/share might just also just happen to pass the voting criteria.
It is not 100% solvable but 0.1% error margin may be within tolerance. I really like the idea of using parts of the header already used (even though I was dubious at first) so I will keep thinking on this.
Seeing as you are running a pool, could you set up where the donation level signals the intent, or an extra pool parameter (be it use password heartwood, or attach to this port, etc) by making the user actually adjust something on their PC that is a trivial adjustment (you could even add an extra flag, vote=on/off you could eliminate the reliance on the checksum for proof of vote as it were)
This could help address the cold storage thing, and you would know how much hashpower is actively involved and how much doesn’t care. This idea is not that great tho. it only helps miners. but we are looking at the specific usecase of pooled mining.
edit: and I will get around to checking how voting impacts the amount of blocks you can find and collision resistance will take me a while tho, I have some other stuff to do first.
Found a method that works, scanned 500000 blocks & no false votes
My “voting nonce” is now :-
start byte 0xff
data (bit7 = bool, bits6-0 = value + 1)
data (bit7 = bool, bits6-0 = value + 1)
data (bit7 = bool, bits6-0 = value + 1)
checksum (sum of data bytes + offset value, mod 0xff)
I’m also checking the data values are in range (1-101). There’s often nulls (0x00) at that end of the nonce & I suspect pools use it to encode a miner client index number, my data range is 0-100 but adding 1 screens that out nicely.
That leaves 216 bits untouched, if bitcoin can muddle through with a 32-bit nonce it shouldn’t be a problem.
Follow up - I found a better way of doing this & it collects inputs from miners (not pools) - downside is it needs a server somewhere.
Basically, its a proxy server - it allows miners to connect and they use the ‘rigname’ field to express their opinions, the proxy forwards their connection to the pool. They get to mine where they want to & get paid for it as before.
Every time they find a share thats accepted by the pool its logged and the difficulty noted - that counts as a vote. The miners difficulty level is needed to ‘normalise’ the vote as the difficulty changes & pools provide different levels.
The proxy would offer a range of ports & each port connects to a different pool so they can mine wherever they want - might only want to offer this for pools that support zaddr payouts
What say you? If there’s enough interest I’ll cobble something together.
Edit: This wouldn’t work for miners using SSL, but no great loss IMHO
