I look forward to finding out what you hope to accomplish with this.

The data field will be unique, at the very least to the server and block in progress.  You can record that with the server it came from.  Or, since you are changing both the proxy and the client, you could just have the proxy add a field that just says what server to give the work back to, and have the client return that when it returns the candidate hashes.

 

The facts are plastered all over these forums, as are all of the opinions for and against the system as designed.  I still don't see how you can continue to claim that there is some sort of suppression going on.  You are free to post your opinion that the system is unfair.  Other people are equally free to disagree with your view, and to post their rebuttals.  Is that what you mean by suppression?  Are we suppressing you by posting our disagreements?

ZOMG!  The stats are wrong!

Yeah, it happens fairly often.  Half the posts in this thread are people either reporting it, or going into a panic about it, each and every time it happens.

It'll be fixed in a few hours, when he wakes up, just like the 30 times before.

The credit card companies have nothing to fear from us.  We need them just as much in a bitcoin world as we do under our current system.

What the hell is a Nebbie?  or a Nebie?

Also, how can anyone possibly look at these forums and pretend that deflation is a big secret that we are trying to hide from the masses?  You can hardly swing a cat in here without hitting a dozen threads on the subject, including the one and only sticky topic in the Economics forum.

btcguild?

Your assumption is wrong.

Every client works on one getwork request at a time, and always the most recent.

Someone that thinks that it will be higher later?

The proxy is not limited to the information in the blocks itself.  It is allowed to keep a record for itself of which server provided the most recent work request for each client.

Is this some new form of trolling?

Step 1) You keep asking the same question.

Step 2) We keep giving you the same answer.

Step 3) You always acknowledge our answer.

Step 4) You apparently forget that wages can go down, and return to step 1.

Or pay you less (in nominal terms).  How do you keep forgetting this option?

I ask again.  Why is it that you think that standard of living adjustments can only go in one direction?

You think that deflation will lead to overpayment, but don't believe that inflation leads to underpayment.

Here is another aspect to consider.

Over time, people tend to find ways to break, or at least reduce, the security of hashing functions.  We understand this, and the bitcoin community is capable of replacing the hashing functions used in the bitcoin system.  This will probably need to be done every decade or two until the end of time.

Cryptographers are very conservative, and they have a tendency to declare a hash "completely broken" long before any real attacks are possible in the field.  Typically, the lag time is several years, because attacks are first found against crippled variations of the hashes actually in use, and then extended until they reach the production version.

Protecting the blockchain is easy enough to do in this environment.  An extension is proposed to allow the next great hashing function to be used, starting with some block a year into the future, and the community will agree because the change is in their own interest.  The appropriate block arrives after roughly a year, and the network accepts the newfangled hash as genuine.  Past blocks are still secure, even though the hash used on them is now weak, or even broken, because their information is included in the new hashes.

Transactions are likewise also safe, since the hash of the Merkle tree will be updated at the same time.

But, what about keys in wallets?

The only way to replace them is to send them out onto the network with a transaction that uses the new hashing system.  Old ones can't simply be updated, because they contain scripts that permanently embed the hashing function in use when they were created.  They must be spent between the time that a new hash becomes available to the scripting system and the time that the old hash becomes breakable in practice.

Realistically, this interval will be decades, or more likely centuries.  But, I think that this compares favorably with the time needed to lose enough bitcoins to matter, assuming that they matter at all, which is far from demonstrated.

So, unless we reach a total dead end in cryptanalysis, old coins will gradually become recoverable.  This is unlikely to cause problems for genuine savers, because they will be able to spend their way into the new hashing systems as they become available.  But coins that are really and truly lost today will gradually gain new life, as the effort required to recover the keys to them decreases relative to the value of the coins lost.

Again, this assumes that future progress in cryptography and cryptanalysis follows more or less the same progression that it has so far.  It could turn out that SHA256 really has no weaknesses that allow anything but a total brute force attack.  But that doesn't seem likely, and we have plenty of time to figure it out.

Shit.  I had a whole reply typed out, but the stupid forums limits the posting rate, and I managed to lose it while going back to try again.

The short version is that I now understand your point.

But I don't necessarily agree that instability is inevitable.  Holders of unusually large wallets from days past will have an incentive not to crash the system.  And as coins are actually lost, the increase in value of the remaining coins will give an incentive for people to recover coins that aren't actually lost, but merely hiding, keeping the ratio of "thought lost" to "actually lost" at a reasonably low level.

So, yes, over time, the loss of coins could cause uncertainty, which could cause instability.  But I don't think that those are inevitable.

I'm pretty sure the exact same procedure used to install it onto a USB flash drive will work on a hard drive too.  I can't think of any good reasons why it wouldn't, except that unetbootin might not be willing.

This is where the third party comes in.


The end result is the same.  You are paying the fee one way or the other.  Option A is to pay the fee, and know that you are paying the fee.  Option B is to pay the fee, but think that you are not.

I think you missed my point.  A transaction can be reversed be the sender, the recipient, or someone else.  In bitcoin, there is no someone else, and the recipient can already reverse transactions by sending the money back.  All that is left is a way for a sender to recall their own coins.  Why would anyone accept what amounts to a loan from you in exchange for anything of value?

All fees are always paid by the buyer.  This is true even if the seller claims to be paying them, since the seller really has no choice but to pass the costs on the the buyer in the form of higher prices.  Note that this is the model currently in use around the world for virtually every non-cash transaction.

Wasting addresses is a good security measure.  A lot of cryptosystems attacks involve comparing multiple outputs from the same key and calculating portions of the key from properties in the repeated outputs.  Historically, I think Enigma was first broken this way.

Generating a new address each and every time reduces the chances of an attack like that being possible, assuming that weaknesses of that sort are someday found in SHA256 and RIPE-MD160.

Oh, and if we assume 100,000,000,000 people in the world, and each of them doing 10,000 transactions each day, it will take 3.8*10^30 years to run out of addresses.  The first address collision will, of course, come a bit sooner than that.  For comparison, the current age of the universe is generally thought to be around 1.3*10^10 years.

Progress won't help.

There are roughly as many possible SHA256 hashes possible as there are particles in the universe.  It would take a computer the size a galaxy a very long time to brute force a collision.

It would take a serious overturning of a large portion of our knowledge of discrete algebra to break SHA256.  Could happen, but is generally considered to be unlikely in the near future.

If you can reverse a transaction for a good reason, you can reverse a transaction for a bad reason too.  And since there is no central authority, your options are "anyone can take back their coins at any time for any reason" or "no one can take back their coins ever".  One of these options is useful in the real world, the other is not.

Transaction risk, which is real, will be handled in the bitcoin world just like it is in the real world.  By third parties that are paid to manage that risk.