You are probably right about that.

Oh, but did you notice that you changed your scheme already?  From "round to nearest" to "round down".  One of those was probably just a silly mistake, the sort that happens to everyone from time to time.  Simplicity has a value that is hard to quantify.


Actually, miners will choose the weight based on whether they got the last block or not, and whether they are getting paid kickbacks to support/override blocks from the previous miner.  For most miners, I think the best payoff would be prevDifficulty+1, except when they are working on extending their own block, in which case it would be the minimum, or close to it.  The exact game theory optimum would depend the acceptable range.


Oh?

Option 1.  You pay "easy" blocks less and put the balance into a fund used to pay extra for "hard" blocks.  Equilibrium at 10 minutes, which is what you wanted to avoid.

Option 2.  You pay "easy" blocks less, and the remainder carries into the next block.  Equilibrium at X minutes, which is no more optimal than 10 was.

Option 3.  You pay "easy" blocks less, and the remainder is lost.  Equilibrium at 10 minutes.

Option 4.  You pay "easy" blocks less, and "hard" blocks more, creating money out of thin air.  Equilibrium at whatever the weight cap is.

Did I miss any?

The subsidy is currently 5,000,000,000 units, giving you a lot of dynamic range to play with.  That will not always be true.  And rounding to the "nearest" satoshi can be gamed, for trivial gain at first to be sure.

Also, I'm pretty sure that your idea will create total chaos.  Not less forks, but more.  Lots more.  Like on nearly every block.  Not at first, necessarily, but as the subsidy shrinks relative to the transaction fees for sure.

The subsidy is based on an exact integer operation.

Maybe they were a gift from someone that trusts you to do the right thing with them.

My personal p2pcoin rig farm found a block.  I haven't been watching every coinbase looking for the [P2COINv0] tag, so this might not have been the very first one found with this setup, but it is the first one that I know of.

Amencon, did your node finish downloading the chains and start up?

Woohoo!  I finally got my first p2pool block.  I had been starting to get worried because my rough estimates of my personal expected time to block had already come and gone.  Even when you know it is an estimate, and an estimate of the 50% probability time, no less, I've gotta say, it can still be hard not to get worried.

0.4 released to upgrade p2pool to 0.11.1.  See forrestv's post.

The network will switch automatically when adoption hits 95%, so there is no hard date.  Better sooner than later, I suppose, but doesn't appear to be super urgent yet.

But our fork would never be overwritten by their fork, because we consider their blocks to be invalid regardless of the embedded difficulty.

Not all, no.  Just enough, which is tricky to define.  If the bulk of the exchanges (which really means just Mtgox right now, but that is an accident of history and not a rule) were on the new rules, that fork would be the most useful fork.  Nodes would gravitate to it, as users that wanted to cash out, or pay people that wanted to cash out, or pay people that wanted to pay people that wanted to cash out, etc, etc, would have a strong incentive to get on.

The nice thing about doing it early would be that it would make a whole class of potential 51% attacks pointless.

Perhaps that should be a little bit less far down on the TODO list after all.


No, because the attack blocks would be invalid, and thus not in competition for the regular blocks, at least with the nodes that have adopted the new rules.

I just tested this out.  I didn't have a brand new USB drive, but I have a pile of old ones, so I used DD to zero out a spare 4GB drive.  Then I plugged it into a windows box (XP) and formatted it as FAT32.  Then used unetbootin on Windows to write the 0.3.1 ISO image and used the Windows USB disconnect thing.  Then I switched off one of my rigs, plugged it in, turned it back on.

Booted fine, mining away as I type this.

I googled the messages you are getting, and they weren't very helpful.  Maybe try different RAM?  Seems like a long shot, but someone else reported success that way.

After you ran unetbootin, did you properly dismount the drive before unplugging it?

Gold has good surface properties for physical connections, but lousy bulk properties for traces.

Also, it is very expensive.  Copper is 3-4 $ per pound, while gold is $1650 per ounce.  A standard circuit board uses 1 or 2 ounces per square foot, per side.

0.3.1 posted.  CD booting works again, at least for me.  Let me know if anyone else has problems with it.

At least one has been proposed.  See BIP 10.

This has been discussed at length in other threads.  I think the most recent useful thread was the one from etotheipi where we discussed a format/syntax/protocol for transaction proposals.  Also, see the "todo" link in my sig.

Ok, the 0.3 ISO posted does fail to boot when burned to a CD.  I'll have 0.3.1 out with a fix soon.

I just tested it by using unetbootin on a Windows box to write it to a formatted USB stick.  For me, the USB boot still works fine.  Is the partition on your USB device marked as bootable?

That's odd.  I've never seen that before.  I'll check it out tomorrow morning.

I just wanted to pop in and say that the stuff I ordered arrived quickly.

Of course, now that it is here, it isn't lasting as long as I had hoped, but that is completely my fault.

With just 50 Mhash/sec, you might have just been unlucky enough not to have any shares in the last few blocks.

In your p2pool logs, look for these numbers:

Local: X MH/sec ... Expected time to share: Y hours.

X should be somewhere near 50, and Y is probably around 12 hours.

My p2pool nodes are running bitcoind in RAM.  I expect this will continue to be practical for quite a while.