Bitcoin Forum
May 03, 2024, 02:52:09 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Pools / Re: Cooperative mining (>10000Mhash/s, join us!) on: January 22, 2011, 05:37:42 PM
I'm not rounding, but flooring with 8 decimal places precision, to avoid divide more than 50BTC between workers. The rest from "flooring" (50BTC - calculated rewards for all workers) is added to random user which participated on the block (it is usually something like 0.000000x BTC or so).

Ah.  Do transaction fees get assigned to a random user too, or when you say "50BTC" do you mean the 50 + any fees?
2  Bitcoin / Pools / Re: Cooperative mining (>10000Mhash/s, join us!) on: January 20, 2011, 03:27:35 PM
But what exactly is happening with all of the trailing "leftovers"

For example, if I have 27 shares in something solved in 5016 total shares, that would be
0.0053827751196172248803827751196172(this goes on and on...)%, translating to

0.26913875598086124401913875598086 coins earned by me for that block.

so what happens?

First, I think it gets rounded off to nanocoins.

After that, any amounts less that 0.01 BTC get collected in your "account" with the cooperative miner until they accumulate to the point where they can be paid.  This is because transactions with outputs (either direct or "change") of less that 0.01 BTC will not be processed by the default code without at least a 0.01 BTC transaction fee.  That's there to prevent someone from trying to DoS the network by making tons of tiny transactions.

I don't think there is anything preventing someone from running a modified bitcoin client that processes nanocoin transactions for free, however.
3  Bitcoin / Pools / Re: Cooperative mining (>10000Mhash/s, join us!) on: January 20, 2011, 03:21:15 PM
My understanding is that once a new block has been found, the data you're trying to hash is no longer valid.

Actually, if I'm not mistaken, the hash changes every time any of these things happen:
a) a new block is created
b) a new transaction is added to the block currently being worked on
c) the nonce field (the thing you increment to try to get a "winning" hash) overflows
d) a few seconds go by (the blocks have a relatively low-resolution timestamp)

For any of these except a, if you find a hash the cooperative mining server could just go ahead and mint the old block.  So what if a few transactions spill over into the next block, or the timestamp is a few seconds old?  It's hardly worth throwing away 50 bitcoins for.  And I think slush's miner already plays games with the extraNonce field to make sure that the clients aren't all trying the same hashes.

If a miner wanted to be particularly antisocial, it could just never accept transactions at all (or perhaps only accept transactions with a fee attached).  Such a miner would simply mint "empty" blocks with only the 50 bitcoin generation transaction in it.
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!