Not sure what you point was.  The title is "DEPRIORITIZE" and that is exactly what it would do.  It creates a method for privacy and security minded individuals to create an incentive for like minded individuals.  Nothing more.  Nothing is being forced.  Nothing is being prevented.

It is still a choice just a choice with consequences.

Donation addresses don't need to be static.  It is easier if static but easier isn't an absolute.  Any address can be made dynamic.  It will require support of sites and services providers but with no incentive no such system will ever take place.

For example Bitcointalk could have a field where user inputs their pubkey seed.  It would then generate the first address from that seed and as you receive a donation it would detect it and rotate the address to the next available one.   Sound like a lot of work, maybe but once implemented it would be copy and paste easy for all users to have a dynamic donation address.  Will it happen without some incentive?  Probably not.

To imply it is forced would imply that the patch makes address resuse impossible, that coins sent to a used address are permanently lost and that isn't the case.

So if they won't issue RMA for 500 GH/s output should they be advertising the unit as 550 GH/s?

The quote is also ambiguous.  So >=500 GH/s is no RMA.  <450 GH = confirmed RMA.  What about 450 to 499 GH/s?

Nothing wrong with learning.   Asymtric encryption never has a strength equal to its key size.  The public and private keys are related mathematically and the mathematical properties which make asymmetric encryption possible also allow more intelligent attacks then simply trying private keys until you find a collision.  ECDSA is actually pretty efficient where key strength of 2^(n/2) is possible for key length of 2^n.  Other methods like RSA require much larger key sizes for the same key strength, 128 bit security using RSA for example requires 2048 bit keys.

A 256 bit ECDSA key despite having 256 bits only provides 128 bits of security.  In other words to send the coins for a known address/pubkey and unknown private key requires either:
a) find another private key which produces the same PubKey.   On average this will require 2^128 attempts.
OR
b) find another PubKey which produces the same PubKeyHash.  On average this will require 2^160 attempts.

If the PubKey is unknown then only B is possible and security improves to 160 bit security.  This is why is is recommended you not reuse addresses.  It provides a secondary line of defense in the event method "a" ever becomes viable.

Security of a system comes from the weakest link and for Bitcoin that means 128 bit security.  Making the other links stronger won't improve security.  

Only against a collision between two random (and essentially 100% chance unused) keys.  Against an preimage attack the security of any unbroken hash of length n is always 2^n.

https://en.wikipedia.org/wiki/Preimage_attack

Why?

256 bit ECDSA only provides 128 bit security

160 bit pubkey hash provides 160 bit security.

What would making the pubkeyhash larger accomplish other than bloating the blockchain?

Yes. 

That is the attack vector you are worried about?  Really?  Couldn't miners just make the coinbase address a non-existent address and destroy coins just as easily or send them to a non-existent address?

As for why not change it?  It is a hard fork.  Hard forks are never trivial.  In practical terms hard forks will probably never be implemented for anything other than critical (as in "oh my god Bitcoin is going to die") fixes.

And leave $3 in profit on the table? $529.98  (not .99 so I can get ahead of all of those suckers)

How do you intend on attaching that to the board?  Duct tape?

BIP32 supports a hierarchy of pubkey seeds.   So a user can generate a pubkey seed ONLY FOR YOUR SITE and upload it.  Using that seed you can deterministically compute an infinite number of unique addresses in a sequence the user will expect.  

Wallet support isn't there yet which is the only negative of moving forward at this time but in theory that is how it would work in the future.  Your site would simply have user upload a seed for all their future pool payments.  You will be unable to deterimine any of the addresses in the user's wallet. You will always be able to generate a new address.  The same address never needs to be used twice.   For added security you could lock the pubkey seed the same way you now lock a single address.

Thats all fine and good hopefully you can see that the same person borrowing the loan "guaranteeing" it is utterly pointless and comes across as scamish.

I mean what would you say "give me this loan and I will never repay you".  All loans are a promise to repay.  You can't guarantee repayment because even if you have the intent to repay you may be unable to do so.  Unless you have a co-signer, guarantor, or are putting up collateral putting "guarantee" on your loan comes across as amateurish (and that is being nice, the first thought is scam artist).

that has no meaning in a debt insturment.  debtors are requirement to make payments, if a debtor doesn't then they have already broken the contract.

It is like saying "trust me, because you can trust me". 

Unless you have a separate guarantor (i.e you personally are willing to put personal credit and assets on the line) it is a stupid statement to make.  If anything it makes the loan more suspect.

Well threshold would imply some sort of cental block planning agency.   Various miners have various different block parameters.  Tx volume is higher than the block size being created by the various parameters currently used by various miners.   Some miners target larger blocks, some target smaller ones, a couple seem to include nothing but the coinbase tx.   Collectively all miners have a certain tx throughput which is less than the tx volume and the limit imposed by the 1MB cap.

Miners can either expand the # of tx they include in blocks
OR
Users can collectively reduce tx volume
OR
The backlog will grow

For the time being a way to put yourself at the front of the line is to pay a tx fee but that won't reduce/eliminate the backlog it will just ensure your tx has a higher chance of going first.

It is very simple.

Tx volume is higher than average block size.  It is THAT SIMPLE.

If users are creating an average of 400 tx every 600 seconds and miners are making blocks with an average of 300 tx every 600 seconds what is going to happen to the tx backlog?

If users are creating an average of 400 tx every 600 seconds and miners are making blocks with an average of 400 tx every 600 seconds what is going to happen to the tx backlog?

If users are creating an average of 400 tx every 600 seconds and miners are making blocks with an average of 600 tx every 600 seconds what is going to happen to the tx backlog?


If it is still too complicated lets try a non bitcoin metaphor.

If you have a pool (mem pool) and you are adding 2 gallons a minute to the pool (unconfirmed txs) and at the same time have the drain open and water is draining out of the pool at 1 gallon per minute (tx being placed into blocks) will the water in the pool rise or lower?  What is required to prevent the water level in the pool from rising?

That is not correct.   A miner could make every block 1MB ~2,400 tx only include the free ones and exclude every paying tx if they wanted.  Not saying they would (it would be stupid) or they should but they could.  Saying the "block" prevents them is a cop out.

Miners decide what tx to include in a block.  The only thing which can't be included in a block is an invalid tx, or a sum of tx greater than 1MB in size.

Essentially all.   None of the last 100 blocks were larger than 400KB.  Only 5 were larger than 300KB.   The vast majority are 100KB to 250KB.  More than 20 are <100KB.   The block size limit is 1MB.

Well the UXTO currently contains paying tx waiting longer than a block although I have been paying the min fee on every tx (even those which don't require it) for two years now so you are preaching to the choir.

Not that is just stupid.  I will take the one which hasn't lost 80% of its purchasing power.

Confirmation time =/= block time.

Average time between blocks is <10 minutes.  I pointed this out in the prior thread but it will likely get ingored again.  Any "answer" which involves miners solving less blocks would mean the time between blocks would be greater than 10 minutes and that is not the case.

Miners are on average producing a block size of ~160KB.
http://blockchain.info/charts/avg-block-size

To clear the backlog and reduce the average wait time to ~1 block would require blocks to be roughly 50% larger.  Miners are chosing not to do that.  The average block has ~300 tx vs the ~2,500 tx limit imposed by the 1MB or ~600 tx it would take to clea the backlog

Simple version: blocks are 90% empty, tx wait longer to be included in a block