How does an empty block (~250 bytes) do you more harm than any other 250 byte, 25BTC transaction?  [All I can see is that it (slightly) increases the difficulty two weeks from today.  But if it included one or more transactions, it would still (slightly) increase the difficulty two weeks from today.]  Yes, it's a lost opportunity to include transactions, but is it really any worse than if the miner hadn't been mining at all?

If it ain't broke, don't fix it.

No leapseconds recently, so this thread is probably not your problem.  [Maybe fuzzter's query should be a separate thread?]

My Bitcoin 0.7.2 client began spending its time at 100% CPU busy a couple of weeks ago.  I was forced to shutdown my client.  Whatever is causing this is effectively a form of DOS, in my opinion.

My client has contained the vanity address for "correct horse battery staple" for many months.  [It's been interesting to watch tiny deposits appear and disappear from the account.]  I suspect the problem is related to the recent block-chain spam involving this vanity address.  Unfortunately, if the standard client provides a method of completely and totally expunging an address from the wallet, I haven't found it.  (I'm aware of a third-party tool to do the job.)  This seems like a pretty serious limitation (and DOS vulnerability) of the reference-standard client.

Coincidentally, at about the same time, my client has been displaying a "nag" message saying "Action required: see http://bitcoin.org/may15.html for more information".  I've already taken the other mitigation steps, but my client continues to be nag me.]

It's probably the block-chain spam causing the 100% CPU?  Maybe it's the nag message causing the 100% CPU?  Or maybe it's some combination of these factors.

BTW, after having had my wallet offline for a little over a week, my client consumed 318 minutes of a modern i7's CPU time over the last ~5.5 hours.  The wallet is now synchronized, but every time I blink, it goes back to 100% CPU busy for minutes at a time.  I can't imagine what the client might be doing that could *possibly* take 318 minutes of a modern CPU's time!

@bitpop:  I don't understand why you think the electrician is an idiot.  Electrician <> Electrical Engineer.  It would not surprise me if there existed some industrial machinery that *did* remember its original voltage settings.  And why should the Electrician know how CPU power supplies are designed?  It sounds to me like he told his friend (the OP) "I don't want to be blamed if the higher voltage burns out your computers."

@snootch:  Nothing in this thread suggests the electrician is incompetent.  He should know what gauge to use for a 20A circuit.

@OP:  I will give your electrician the benefit of the doubt and assume he is doing everything by the book.  Most jurisdictions require you to pull a permit, even for DIY work of this nature.  Your electrician friend shouldn't mind as long as you pay the permit fees.  You get the benefit of having the work inspected, and the permit fee sometimes let the materials be purchased free of sales tax.  In the worst cases, without a permit, your insurance might not pay off, or you might not be able to sell your home in the future, or an overzealous code-enforcement department might even try to condemn your property.

There may be restrictions on where a 240V outlet can be placed in a residence.  [The kids' bedroom might not be a good idea.]  And unlike 120V circuits, which can feed multiple outlets, a 240V circuit may be limited to a single outlet.  [A 20A circuit will be overkill for one computer with a 5A power supply input.]

You do understand your savings won't be half?  Power = Voltage * Current.  So twice the voltage and half the current results in the same (approximate) power consumption.

As others have said, some of your savings will be in lower losses from your electrical panel to the back of the computer.  If you really want to be as energy efficient as possible, consider asking the electrician to use the next smaller gauge (larger diameter) compared to what code requires.  The wire will be more expensive, but you might make that back over a few years.  You could get some of this benefit by sticking with 120V circuits, but rewiring from 14 gauge to 12 gauge, for example.

The label of an HP power supply I am looking at says the input is 10A at 100-127V, and 4A at 200-240V.  That suggests the power supply may be more efficient at 240V.  Your power supply labels don't suggest a big difference in efficiency, but the manufacturer's Web Site may have better specs that would tell you if there is better efficiency at the higher voltage.

Finally, do you have a 240V electric dryer or electric range outlet in your home?  If you can find a cord, you could test before you rewire.  First, if you are concerned about burning out your computer, remove all of the expensive GPU cards and drives and test with the most bare-bones system you can.  I don't know if there is a 240V Kill-A-Watt meter in the US.  So, when you decide it works, turn everything in the house off, including the refrigerator.  Go out and see if the meter has stopped spinning.  Then turn on one computer, plug it in to 120V and fire up your miners.  Go out and watch the meter.  Time how long it takes to go around once (or a few times).  Then plug it in to 240V and fire up your miners.  Go out and watch your meter, again.  You probably can measure a 5% change in billed power consumption.

Untried.  But *should* work without using any non-standard tools and without risk to your existing wallet.  (Note step #2 !!!)

1.  Export the private key which was the source of the funds for the $0.2805BTC transaction.

2.  To be safe, use a different computer for the following!  I'm not responsible if you mess up your original wallet!

3.  Create a brand new wallet on the different computer.

4.  Import the private key you saved in step 1.  With most wallets, the import should kick off a rescan of the block chain.

5.  Assuming the client running your new wallet isn't talking to the client running your old wallet, the new wallet will only see what's in the block chain.  (And you say the blockchain still has your $0.2805BTC.)

6.  Send the money from the new client.  You can send it back to yourself or you can send it to the originally intended address.

7.  When the transaction created in #6 gets some confirmations, the original transaction will become a failed "double-spend" attempt.  All should be well.

Good luck.

[Edit:  
Revised #6.  Send *all* of the money from the new wallet back to yourself.  (To a receive address known to the old wallet).

Otherwise, be aware that your new wallet may send change back to a (possibly hidden) address known only to the new wallet.  Be sure all the expected money appears in your old wallet before you even *think* about destroying the new wallet.  You may need to explicitly send the change seen only in your new wallet to an address known to your old wallet.]

As much as I dislike SD's (and other's) abuse of the blockchain, this is a bad idea.  First, any idea that is admitted to be "temporary" should be suspected of being a bad idea.  Second, IMHO, it is philosophically wrong -- at best a band-aid for a bigger problem that needs a different solution.  Third, it's debatable whether or not this change will alter the behavior of those (ab)using the blockchain.  The motivation of gamblers is different.  I don't see how it will have any impact on them, other than to change the "dust" amount from 1 unit to 5430 units.  Those storing data in the blockchain will just move data around in units of 5430 Satoshi, rather than disposing of units of 1 Satoshi.  But fourth, I fear the technical issues have not been fully considered, and that's my main objection to this scheme...

One technical problem noted somewhere in this thread is how do you deal with change that's under the limit.  If you are a "bitcoin millionaire", it's probably not much of a problem.  If you are just starting out, it might be a significant problem.  Say you have 0.01005429 BTC to your name.  One rule says you can't spend less than 0.01.  This new rule says you can't spend between 0.01000000 and 0.01005428.  (I haven't looked at the code.  Does the client fail?  Are you forced to overpay the recipient?  Are you forced to pay your change as part of your "fee"?)

If you overpay the recipient, I suspect there are some automated systems that either (1) won't accept the payment or (2) might attempt to send your change back.  You are requiring modification to any such automated system that now exists.  You are also requiring modification to every other standard bitcoin client (else some transactions that used to go through will not go through).  And you are requiring potential modification to every application that generates its own transactions.  This proposed modification has consequences far beyond the official Satoshi client, and as far as I can tell, there has been no general solicitation of comments.

Similarly, what if you have one account with just slightly more funds than needed for a transaction.  Does the client automatically choose a second account to make sure the change is at least 5430 Satoshis?  I thought one of the goals of the client was to avoid mixing payment sources as much as possible to maintain some "privacy".  Although this shouldn't happen often, if you are dealing with random amounts between a bitcent or two, it seems this would occur about 1 in 300 such transactions.  (Again, not a problem for "bitcoin millionaires", but a potential problem for those just starting out.)

Another technical problem noted (but dismissed as irrelevant by some developers) is the increased window for double-spends.  Deny it if you want, but when each mining pool (and each full node) can choose parameters to decide whether or not a transaction is to be relayed, I think the surface area for double-spends has increased significantly.

Related to the above is the question of a node's "banscore".  I haven't examined the code.  If node B receives a transaction from node A, which node B thinks is non-standard, does node B bump node A's banscore?  I won't speculate on the implications until I look at the code, because this might be a red herring.

Finally, in many respects, you are trying to achieve results similar to that of a "5430 to 1 reverse stock split".  Of course, I'm not actually proposing this!  But some of the things corporations and stock exchanges go through when handling a reverse stock split might be considered in handling this proposed change.  Do you want to consider making every transaction output a multiple of 5430 Satoshis?  If it were a more round number, such as 5000 Satoshis, this might actually make sense.  For your very small "stockholders", the way I see it, you are changing the value of very small balances from "economically unspendable" to "practically unspendable".  To avoid a perceived hit in public confidence, the Bitcoin Foundation should send up to 5429 Satoshis to every address now containing 1 Satoshi of "dust".  (Or whatever amount is necessary to bring every address up to the minimum spendable amount.)

I have also been having problems the last 3 days.

I have a linux system with two NVIDIA cards, mining with two instances of rpcminer, each pointed at mining.eligius.st:8337.  I haven't touched the configuration of these miners in several weeks.  Just in the last days, each instance stops finding shares (at different times) until I restart them, yet each instance keeps its GPU busy.  This happens a couple times a day for each instance of rpcminer.  Would it be worthwhile to switch over to mining.eligi.us?  Or has your new DNS become stable?

I also have a new system, with a Radeon 7950.  The system is in flux as I have switched off between Windows 7 and Windows 8.  Having limited time, mining hasn't been my top priority, but I did configure the default Eligius pull-down server option of guiminer (v2012-12-03).  It worked well the first couple of days, giving a fairly consistent 400 MH/s.  But over the last three days, it reports incessant, but intermittent "connection problems".  Eventually, it stops mining until I Stop Mining/Start Mining.  The default Eligius pull-down uses poclbm, pointed at mining.eligius.st:8337.

I'll try BFGminer for the 7950, but that wouldn't explain the similar problems with my Linux system.  The only things common between the two systems are the networks and computers from my ISP to your pool.  It seems likely you have changed something on your end.  Perhaps your new DNS provider or your new DNS configuration?

With the existing vanity pool, neither the customer nor the pool operator bear much risk.  The risk belongs to the vanity pool miners who may toil for no reward or who may get a lucky break and a big reward.  The goal of your project, as I understand it, is to reduce the risk to the vanity pool miners.  You've done enough math on the forums and on your own Web Site I'm sure you understand the risks that a Poison Distribution brings to a PPS pool operator.  If you can handle the risks, I agree that PPS does make the most sense.

Another option is to shift the risk to the customer requesting the vanity address.  When the customer's funding is exhausted, miners won't work on the customer's vanity address until more funding arrives.  If a miner finds the solution early, you would refund the unused funding to the customer.  Other variants might be to allow your customer to specify both the total funding and a fixed PPS or to specify total funding and PPS as a fraction of remaining funding.

I hope you *do* allow pattern-hopping.  My version of the vanity mining client is customized in several ways.  One customization is that I will not submit work that I consider to be too cheap.  Even if one customer with a common public partial key has a collection of work that can be performed simultaneously, if the value of certain vanity addresses within the collection is *too* cheap, I won't submit those.  (I'd rather pour out my milk than sell it at a price that's too low.)  In turn, I evaluate the value of the collection of work differently than the standard miner evaluates the collection of work.  Thus, my preferred pattern is often not the same as the standard miner's preferred pattern.

If you implement PPS and pay as shares are discovered, you could probably implement your project with no changes to the existing vanity mining protocol.  Just make sure your site offers shares (5- or 6-character shares, perhaps) to any oclvanityminer who comes knocking.  For transparency, your Web Site should show the true (7- or 8-character) vanity address being requested along with total funding, and PPS formula.  But the mining client only *needs* to know what it will be paid for.

A client asks for an 8-character vanity address, knowing the cost is too high.  After one (or more) 7-character partial matches have been found, the client cancels their request.  Now what?

Maybe the client wanted a 7-character address in the first place.  Depending what information is public, the client may have their 7-character address for free, and neither you nor the miners get anything.

Maybe the client wanted a 7-character address in the first place.  Even if partial matches are secret, a miner who found a 7-character partial match may negotiate with the original client for the 7-character match.  Neither you nor the other miners get anything.

I would suggest that a refund should deduct *something* related to the value of work done so far.  The deduction to be paid to the miners for work already performed.

If you choose a sophisticated pool payout method, like those used by some Bitcoin mining pools, where payouts may carry over from one block to the next, then the algorithms must be adapted (significantly) for this project.  Unlike Bitcoin mining, where every block reward is the same and difficulty changes modestly every couple of weeks, each and every Vanity job payout is different and the difficulty may vary by orders of magnitude from one job to the next.  Further complication is that two (or more) Vanity jobs may be in progress at the same time.

You may have to develop your own payout scheme that will lure vanity miners whether a job is new or old, even if "luck" (as used by some Bitcoin mining pools) is bad.  The fluctuations you can withstand (PPS) and fees you charge will have a big say in choosing payout schemes that are mutually beneficial to both you and the miners.

Also, I don't see any need for the server to generate the random starting point in the ECDSA keyspace.  The mining client chooses their own starting point, and the probability of overlap (with a fair client) is negligible.  To avoid cheating, you should keep the partial matches and don't award credit for duplicate matches.

It sounds like an interesting project!

To the user who requested vanity address 1CoLBRo: 

My miners found
  1CoLBRohNZyGDw6HhALzpjDDsZh7aj9Zr5
 and
  1CoLBRoNqYHbK71n2R3cyiQDUr31VAG57U

But my finds were after another miner on vanitypool found you an address.  If you want either of these additional addresses, send me a PM.

I have never had a stake in whether BFL "shipped", "ships", or never does either.  Nothing ordered.  Nothing wagered.  Just an observer.

If you are "shipping" from Kansas City, Kansas, but aren't shipping your product in a manner could qualify for U.S. Trademark protection, can you honestly say you are shipping?

http://www.fr.com/Dont-be-confused-about-whether-your-trademark-is-used/

See below.

I would describe it more as one SHA-256 hash then one RIPEMD-160 hash.  It's the 160-bit RIPEM hash that is presumed to be unique.  The other two SHA-256 hashes are for computing a 32-bit checksum for the 160-bit hash.  This is so typographical errors in an address won't cause a transfer to go to the bit-bucket.  (bitcoin-bucket?)  [There's about a 1 in 4 billion chance a random syntactically correct sequence of bytes will be accepted as a valid address.

private key --> ECDSA --> public key --> [SHA-256] --> [RIPEM-160] --> (pre-checksum) address


On address collisions:  There is no proof that collisions cannot occur.

If our hashes are perfect, there is no way to steer a particular public key to a particular 160-bit hash.  The birthday paradox says we will have to encode about 2^80 public keys before we have a 50% chance of an address collision.

Weaknesses have been found in many hash algorithms.  But, since the input to RIPEM is not under our direct control (input to RIPEM is an output from SHA-256), I think the chances of manipulating the inputs to RIPEM to deliberately produce a collision are low.

Can we get collisions in the SHA-256 output?  The birthday paradox says we will have to encode about 2^128 public keys before we have a 50% chance of a collision in the SHA-256 output.

We do have direct control over the inputs to SHA-256.  While there are cases of two distinct inputs producing identical MD5 (128-bit) outputs, I am not aware of that feat having been performed for SHA-256.

Even if two SHA-256 hashes are found to be identical, the input to SHA-256 was a public key.  At this point, the answer to your question is "yes".  Two private addresses share the same public address.  There remains the problem of converting your hand-crafted public key into a private key that you can spend.  We know it exists, but you can't figure it out any better than you can figure out anybody else's private key from their public key.

IMHO, there are more potential attack vectors aimed at public keys than most other security aspects of Bitcoin.  A fatal flaw in RIPEM could lead to an attack against addresses.  A fatal flaw in SHA-256 could lead to an attack against addresses (and other components of Bitcoin).  And a fatal flaw in ECDSA would be fatal to Bitcoin as we know it.  I'm not too worried.  But ask me again in 20 years.

Many if not most jurisdictions already have such regulations.  Whether it's cash in the local currency or bitcoin, you may already be required to report and/or pay a certain percentage of your wealth each and every year to the king, the governor, or to their representatives.  I think this harks back to the days where you would hand over a share of your pigs, goats, and grain to the local tax collector.  The laws are usually very general -- "anything of value".  There's no shortage of real-world examples.  See the following links:

  http://en.wikipedia.org/wiki/Wealth_tax
  http://www.artkabinett.com/content/frances-wealth-tax-explained
and http://www.irs.gov/Businesses/Small-Businesses-%26-Self-Employed/Estate-Tax

This is nothing new or unexpected.  From a government's point of view, bitcoin is just another asset to be taxed and regulated.

First, let's be absolutely clear that nobody without the private key will have any idea the two addresses are connected to the same EC secret.  So, aside from the owner of the private key(s), they are as different as any other two distinct public addresses.

For the owner of the private key(s), they are (or should be) the same.  It is my contention that a wallet that doesn't recognize both public addresses is deficient.  [But I suspect most wallets are deficient, by my definition.]

As kjj explained, you haven't lost the funds.  But you may have to convert the private key from one form to another and then import the other form of private key to gain access to those funds.

Here's an experiment:  Send a tiny amount of coin to the uncompressed brain wallet for "correct mule battery horse", which I gave a few posts up.  Send a different tiny amount of coin to the compressed brain wallet for "correct mule battery horse", which is given above.  Add one private key at a time to your favorite wallet.  See which transaction(s) show up in your wallet.  Do not send more than you want to lose, because anybody who reads this thread may transfer the coins out of the brain wallet.

Once these transactions are in the blockchain, everyone who reads this thread could add one private key at a time to their favorite wallet and they can see for themselves which transactions appear in their wallet.

The Web site at bitaddress.org (or the equivalent script you download to your own computer) can do the complete conversion for you.

1.  Under the BrainWallet tab, enter a phrase.  I will use "correct mule battery staple".
2.  The BrainWallet page generates an (uncompressed) bitcoin address of 1Aop6KxiZLccPPPjqmfZHYgnmCKuhiVq57, which we will ignore.
3.  The BrainWallet page generates a private key of 5JRks4Vf268r9cuCKiod2iFz1VcSpawX5m6T3PKSA1v7cRqfZZD, which we copy over to the WalletDetails tab.
4.  The WalletDetails page generates a compressed bitcoin address of 1JMsC6fCtYWkTjPPdDrYX3we2aBrewuEM3, which we can give to our payors.
5.  The WalletDetails page also generates a bitcoin private key, flagged as "compressed", of KyvGbxRUoofdw3TNydWn2Z78dBHSy2odn1d3wXWN2o3SAtccFNJL, which we can import into a wallet that supports the compressed keys.

You are now a good citizen.  As always, test your own generated BrainWallet (receiving and sending) on a very small amount of BTC, before you trust anything substantial to a BrainWallet or any other manually concocted wallet.

Very cool graph!  But I'm not sure if it tells much of a tale.  There's no hint as to how many distinct Tx packets you are seeing.

I don't claim to be an expert on the Bitcoin protocol.  I only know what I've observed.

With respect to the long tail, I think that could happen if a node was offline when the packet originally traversed the network.  Later, when the node rejoins the network, it receives the Tx packet from one of its peers.  I think it retransmits that packet to each peer it subsequently connects with.

I think this may also occur as connections between peers flap up and down.  Doesn't each new "up" connection result in an exchange of some queued Tx data?

You said you had 1900 connections "at the end of the experiment".  I would expect a connection you made 20 minutes into the experiment to send you the transaction 20 minutes (or more) after the start of the experiment.  So, did you track the time between when you last connected to a peer and when the peer next sent you the Tx packet?

A useful overlay would be the time between when you first see a packet and the time when it enters the blockchain.  I think the slope of your long tail is partially dependent on how quickly packets enter the blockchain.

@Otoh:  Thanks for the info.  But, I think 1ELiZABETH would be among the lower-difficulty 9-letter vanity addresses.  Compare "1NewYork1" (8 letters) to "1p2pCoin" (7 letters) in the table, below.

@all:  The table below shows what is on vanitypool.appspot.com, sorted in descending order of Satoshis per gigakey.  The raw data came from the oclvanityminer with the verbose option, and with the printf tweaked to show Satoshis instead of uBtc.  oclvanityminer always takes the top item from the sorted list and works on it.  "1Douglas" would take about a day on my hardware and would pay 0.008 BTC.  Next, oclvanityminjer would pick up the 2 patterns submitted by 04262ADA.  (1andreas and 1aantonon).  "1andreas" is more likely to be found first, it would take about 2 months on my hardware and would pay 0.40 BTC.  Then 2 more months to find "1JohnGalt".  Then 2 more months to find "1gSILVER".  But this is my hardware.  Let's consider a serious miner...

Using the data from here, and taking the best AMD hardware for vanity mining currently on the Wiki (a Radeon HD 5870), and the highest paying pattern on vanityminer.appspot.com, a Vanity Miner will be paid about 916 Satoshi/Gkey * 30 Mkey/sec * 86400 sec/day = 2374272 Satoshi/day = 0.02374272 BTC/day.

Using data from the same table, and current block difficulty, a Bitcoin miner with the same hardware could expect to earn about 400 Mhash/sec * 86400 sec/day / 2^32hashes/share * 25 BTC/block * 1 block/6695826shares = 0.03004344 BTC/day.

(I hope somebody will check my arithmetic, but I think this explains why your vanity addresses aren't being mined.  As I said before, I'm experimenting, I'm very far from profitability.  @Otoh:  You've been lucky.  Of course, you have also benefited by having 30 to 40 address being mined concurrently.)

@gyverlb:  Are these numbers in line with your choice of vanity mining versus Bitcoin mining?



Update:  Correction to formula for bitcoin mining

You're welcome for what I did:  I found 1Tarot78 and 1Hashing.  Nothing else for a while.  So, there are other vanity miners doing the majority of your work.  The 1Tarot78 prefix was extremely lucky, because it was equivalent to some 8-character vanity addresses.

I think the vanityminer idea is a pretty cool idea.  The prices are so low, I'm not even close to making a profit, but I'm in experimental mode.  For new people like jaywaka2713, they don't really know whether or when miners will get to their work.

I would suggest a sort of bid/ask criteria.  (I privately mentioned something like this to ThePiachu, but he said he doesn't have time.)

One idea is to have miners work on posted requests, but allow the miner to put a price on their work.  "I've solved your hash, but I'd like to receive X.XX BTC for my work."  As with any other market, when bid and ask meet, the transaction takes place.  Here, however, the market is quite thin.  There may be multiple sellers of the solved hash, but there is only one possible buyer.

Maybe a better idea would be for miners to advertize their rate.  Something like "I'm only working on hashes valued at over 8000 satoshis per gigakey".

Customers also need a better idea of the difficulty of their pattern and the value they are offering to miners.

Did you know that a vanity address that starts with an upper case R-Z or a lower case letter is about 58 times harder than a vanity address of the same length that starts with a digit or an upper case A-P?  So, "1Stryker" or "17Stryker" would take about 2 months on my hardware, while "15tryker" would take about a day.

Just some ideas.

It seems as if vanitypool is having some trouble today.  I solved 1Hashing, but it isn't accepting my solution.  Maybe the deduction from 7Stryker is related to my problem.  Was your 20% fee already deducted?

ThePiachu said "the more you pay the faster the miners will get to your work".  That's true.  But below a certain threshold, few, if any, miners will spend cycles on your work.

The standard oclvanityminer client appears to work exclusively on the highest valued set of patterns.  At the present time, there are several patterns (about ten, I think) with higher values than what is showing for 7Stryker.  [So 7Stryker is probably not getting any attention, and won't get any attention for a while.]  For example, the group of keys with public key starting with 04C13D9C has a combined value of about 1500 satoshis per gigakey, as reported by the oclvanityminer client.  Your key has a value of 126 satoshis per gigakey.

Different miners will have different criteria, of course, but before the price dips to 126 satoshis per gigakey for Vanity Mining, I think most vanity miners will have switched back to conventional mining or turned off their miners due to cost of electricity.

@etotheipi:  Thank you for the clarifications.