I'm not assuming anything.  I'm telling you that the exact thing you are talking about happens every single day.  Not the coersion, but the forking of software projects and the changes in development teams.

Different lead developers would take over the old fork.  It happens every day in the open source world, usually when someone gets burned out.

Heh.  They are related.  Google FPGA, ASIC and VHDL.

Do your calculations again with a difficulty of about 70,000,000.

A company selling a product rarely acts like a market.  They can if they choose to, but most don't.

Once the products start getting out into customer's hands, it is likely, maybe certain, that there will develop a secondary market with prices set, more or less, by supply and demand.

Someone (you or a pool) generates a block and a partial header for that block.  That partial header is sent to your mining system.  The miner completes the header by hashing the initial part of it.  If the result of that hashing is low enough, it gets sent back up the chain and becomes either a share in your pool, or a block in the chain.

There are no fields for IPs in blocks or transactions.

p2pool doesn't have a criteria.  Each individual p2pool node sets their own criteria.

You can look at the share chain and see if and how many shares were created that did include that transaction, but that doesn't tell you anything at all about the next share or the next block.

It isn't just raw speed, it is speed per dollar, or speed per watt.  If you can plug in a low power USB device that verifies sigs as well as your CPU, that's a server you don't need to buy, power and cool.  Might be worth looking into, I'm not saying it is the answer.

Well, are we in the innovative cryptography business, or the innovative money business?  I know that there is some overlap, but I'd prefer that we be as conservative as we can be and let other people take the risks that we don't absolutely have to.  Not that I think that there will be a zero-day released for Secp256k1 some day...

This would centralize control of p2pool, and would destroy it.  People mine on p2pool because it allows them to control the blocks that they create.  We will reject any proposal to force us to include transactions that do not meet our own local policy.

Check your debug.log, that should tell you which database is causing the problem.

Likely bet is addr.dat.

Regarding the curve, I'd really prefer moving to a curve that is better trusted than to one that is faster.  Secp256k1 isn't widely used, and some people consider it unsafe.  Well, not unsafe exactly, maybe nervous; they don't have the confidence in it that they have in some other curves.

If there are optimizations known for popular, widely trusted curves, that would be best.

One small downside to the rise of FPGA/ASIC mining is that miners won't automatically have piles of nearly-idle CPUs sitting around managing their GPUs that could participate in pooled verification schemes.  (I'm thinking something like distcc)  I'll shoot the BFL guys an email, they'll soon have piles of FGPAs sitting around as they buy them back from people upgrading to ASICs, maybe they'd be interested in repurposing them as signature verification devices.

Any idea where the smoke is coming from?  You might have a bad drive, or a bad power supply.  If you only have one of each, it might be hard to tell.  Sniffing might help locate burned parts.  If the smoke is coming from a wire, it might be hard to pin down, but if one overheats the insulation will melt and become brittle when it cools, and you should be able to see or feel that.  That was sorta common on 3.5" floppies back in the day because the connector had enough slop that you could overpower the keys and plug it in with an offset, causing an instant short.

Oh, and are you using a SATA-power connector on the drive, or a molex plug, or both?  (don't ever use both)

If the power supply is modular, double check the connections there, then triple check them.  If using an adapter to convert molex to SATA-power, check that.

Well, there would need to be a hard fork.

What really happens is that the tx_out contains a field of int64_t with the value in protocol units (a satoshi currently).  I think that much more likely than adding 3 more places and keeping int64_t, we'll go to int128_t and add a whole bunch more places.  Either way, it would require bumping the transaction version number, and that would break all old clients (more or less, I don't remember off the top of my head if that is a hard fork or not, I think it is, but even if it isn't, it would still mess them up pretty bad).

It is actually a good thing that int64_t has a lot of headroom above the maximum number of coins that can ever exist.  It means that we can still use 64 bit math to do (exact) accounting of value denominated in satoshis.  For example, at current market prices, we could do accounting for a 400+ billion USD entity in bitcoin before we have to start worrying about running out of bits.

A quick look at recent blocks will reveal the lie.  In that sense, the fees are already being broadcast.

Gavin said that he is planning to change the default behavior from "high priority first" to "high fee first".  Once that is done, it will become the new default for most miners fairly quickly.

People are working on various parts of this, but there isn't much urgency yet because virtually all miners just follow the default rules.  And the default rules are more of a spam prevention thing than real fees.  But the snowball is rolling.

Yup, you can buy modified cables, or do it yourself.

To do it yourself, get a razor and cut out the +12V lines in the ribbon cable.  You want them separated from the ribbon, and cut from the motherboard (plug) side, but still attached to the card (socket) side.  Strip the ends, then attach to the yellow (+12V) lines of a molex adapter.  If you have some dead 12V fans, those are a good source of molex plugs, or buy splitters.

If that didn't make total sense to you, or if you don't know how to find out which wires in the ribbon you need to work on, please for the love of god, search for better instructions.  There are probably tons of threads right here on the forums about this, and maybe dozens of external websites that show how to do it in more detail.

Those pins burn because video cards split their power draw between the PCIe power connector and the PCIe slot.  Why a big video card with extra power jacks draws any current from the slot is a mystery to me, but they do, and if you have a bunch of cards that handle the split poorly, it overloads the +12V pins on the ATX connector, and they overheat and burn.

That's not what counterparty risk is.  Counterparty risk is when someone owes you.  What you are saying is merely being part of a modern society.

You have a car.  About 98% of the usefulness of a car actually comes from things other than the car:  roads, gas, mechanics.  They aren't counterparties, and that isn't counterparty risk.  That is, er, societal risk or something, because your society could decide (somehow) to stop having those other things.  The good news is that for most of us, if those infrastructures go away, we'll be dead long before we have to worry about money.


Gold trades easily where the gold physically is.  Bitcoin trades easily where the bitcoin network is, which at this point is pretty much everywhere all the time.  I'm going to have to give the advantage to bitcoin on this one.  There is no reason why you couldn't trade gold electronically too, which would even that field, but the only way to do that is to trust a counterparty to owe you gold and reassign their debt to the new owner.  (There are services that do exactly this, of course)

By the way, congratulations on your stack.  I'm more of a silver guy myself because I can afford bigger stacks of it, which are more fun to play with, but I have a couple of tiny gold coins and they sure are pretty.

I wonder if plating techniques like ENIG might work.  ENIG would be a huge pain in the ass to set up and do right, but maybe something similar.

Ugh.  I could have easily gone another year without hearing that name again.