It doesnt stop reuse, it just means they wont clear as fast. So what.
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.
|
|
|
I voted for "don't do this". While we should definitely encourage people to use bitcoin in privacy-friendlier ways, we should not force it upon them. We should simply make it a default, but still an option. People like vanity addresses. Donations need single addresses. If people want to give their privacy away by re=using addresses, we should let them and not de-prioritize them. Privacy should come at the CHOICE of the user, not the FORCE of the miners.
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.
|
|
|
They are already doing this. Hi, Apologies for the delay in reply. If the performance of your miners now average 500 GH/s + we are not able to issue an RMA. If your average hash rate is lower than 450 due to the die issue then we can issue and RMA for a replacement. If you have any further questions please do not hesitate in contacting us. Best regards | Med vänlig hälsning Keith Gurnett 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?
|
|
|
Probably because I don't have a clue, and am just on the verge of trying to understand? 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.
|
|
|
160 bit pubkey hash provides 160 bit security.
R u sure? I was thinking that 160-bit hash provides 80-bit 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
|
|
|
I agree that public address should be a 256bit hash, too.
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?
|
|
|
Ok, let's assume that BIP0032 will be used. Is it possible to create new addresses with PHP or Javascript, without access to a bitcoin client?
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.
|
|
|
Oh, one more thing. First crash was around $32. Second crash was $234 higher (around $266). So logically, the third crash will be... $553? Taking into account that the $32 and $266 bubble are 2 years apart, and the current bubble and $266 bubble only 0.5 years. So that would make (266/32*0.25)*266 = $553 (rounded up) Correct, sir, very sharp. I suggest you hold your coins until around $550 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?
|
|
|
The only fix on this I can see would be on my end adding some kind of "wallet queue" to accounts where they can pre-make a batch of wallets to use (maybe even using the BIP32 suggestions), but my limited knowledge of BIP32 leads me to believe this would still require manual entry on the user part. If somebody else could generate the chain of public addresses to use, it seems like it wouldn't be very anonymous (they'd actually be able to follow all your transactions forever on that wallet-chain?).
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.
|
|
|
Guys... everything that everyone has said in this thread so far has ALWAYS BEEN TRUE (not paying transaction fees leads to long confirmation times, sure). None of that explains why the confirmation times are spiking NOW.
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's it, right here. The block only permits a limited amount of zero fee transactions to be included, and any additional transactions must meet the criteria for the fee schedule to be included into a block. 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.
|
|
|
what blocks are 90% empty and there is a back log?
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.
|
|
|
Simple version: blocks are 90% empty, tx wait longer to be included in a block
Pay 0.0001XBT fee, or 0.04USD, will solve the problem 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 gold but GoldCoins...
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-sizeTo 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
|
|
|
|