So then the cost will get too cheap and the network will still be unsustainable... Prices cannot be determined with a formula!
|
|
|
Bitcoin doesn't have a flawed economic model...
The limited rate of domain creation is a more important issue than the total number of useful domains. When demand outpaces supply, prices will quickly become uncompetitive. The price of registrations should reflect the resources that are actually being used by the network (disk space, etc.), as well as the demand for particular names. This is properly done through the free market. Prices should not be fixed according to some formula, which is what Namecoin does.
Domains are very unlike money. A fixed supply is not desirable.
|
|
|
I'm not proficient with low-level bitcoin stuff yet, but... is such a transaction possible then?
in: 0.01 from a valid bitcoin address out: 0.00 to arbitrary data / public key (induced fee: 0.01 to the miner)
Yes -- that's how it would be done. 0-value outputs are valid.
|
|
|
Why is it broken? The cost of registrating domains will fall 50% over whatever period I forgot.
There's a limited number of domains, which is unsustainable. No formula will be able to predict demand.
|
|
|
Hang on, you're saying that sending arbitrary data in a transaction with a fee is possible and accepted by mainstream clients? That's not what I've heard on IRC...
It's impossible to distinguish between a valid public key and arbitrary data. Pretend that the data is a public key you're sending BTC to. The size is pretty limited when you do this, but it's more than enough for a hash.
|
|
|
There aren't enough posts about it yet. I expect Namecoin to fail, anyway, since its economic model is broken.
|
|
|
But I don't think that's currently possible, so that's why I was suggesting adding processing of non-standard transactions to the mainstream client (with a fee of, say, 0.01 BTC for 32 bytes).
It's entirely possible right now. You can put the hash in a standard OP_CHECKSIG output with 0 value and bypass IsStandard, even.
|
|
|
This doesn't solve the incentive problem. A simple timestamping chain couldn't work, for example. For these cases, it makes more sense to put the hash of a message in a Bitcoin transaction and transfer the actual message through other means.
|
|
|
Okay, new question then, as I've never heard as to why this is:
Why does change happen in this way? Couldn't the protocol simply allow you to only send so much of your balance from one address (say I have 10 btc at address 1X, and I send 5 of it to alice) and the rest just remains there?
You can only spend entire coins. Otherwise, the system would have to track balances for inputs (or addresses), which would add a lot of complexity and probably break some things.
|
|
|
I didn't think that WPA2 suffered from such flaws. This is surprising.
Edit: Apparently WPA2 using TKIP is vulnerable, but WPA2 using AES is not vulnerable. That is probably what they're referring to. At least I hope so.
AES is still vulnerable. It's a problem with key exchange. During the initial handshake, the session key is generated by hashing the pre-shared key concatenated with a random number that is transmitted from the AP to the client unencrypted. Anyone who intercepts the random number can generate the session key if they also have the pre-shared key. EFF proposes doing the key exchange using public-key cryptography, which would be secure as long as you know the AP's public key. If you don't know the AP's public key, then it's not any more secure.
|
|
|
You were breaking a 32.29 BTC coin. The change was .00000001. In order to send a transaction with outputs less than 0.01, the network requires a fee of 0.01. This would obviously be pointless, so Bitcoin just threw the BTC away.
|
|
|
Ahh I see, so if i used the same 100 addresses three years ago then I would have all my btc up to date right?
Not if you sent many transactions.
|
|
|
Is WPA not widely used by smartphones, then? Where is the downside to WPA that the EFF makes the complaint without mentioning this?
Under WPA2 all the users on the network can calculate each others' session keys and eavesdrop on each other. With our suggested design, that would cease to be possible. This attack is more difficult than the article implies, but it is possible. A public, Starbucks-type access point using EFF's PKC scheme would not be much more secure than "open" WPA, since most users would still be vulnerable at the initial handshake to a MITM attack. However, it would be a great improvement on home networks where you connect to the same AP a lot.
|
|
|
Oh, I get it - when the client generates the block, it includes the transaction for the generation bounty in the block, so that transaction can pay out to anyone, and this is valid so long as the total payout = 50 BTC (or whatever the bounty is at the time) + transaction fees. Right?
Would it be possible for a miner to create extremely erratic payouts (i.e. distribute the bounty to a million addresses) as a vector of attack? Or would the block be rejected in that particular case for being over 1MB?
Right. The generation is just an input to a transaction. The value of the input is found by the block subsidy + fees. The outputs follow the normal transaction rules. The generator could easily create a giant generation transaction with tons of garbage outputs. You don't even need to pay out to the outputs: 0-value outputs are valid. The block size is limited to 1MB, though.
|
|
|
It must have been deleted by the author. It was in this topic: http://bitcointalk.org/index.php?topic=6284.msg101804#msg101804He did respond to that post with a fairly long explanatory post, but it's gone now. I don't remember who it was. I seem to remember it being someone new, who had not participated in that discussion recently (or maybe not at all). I could be wrong, though. Deleted posts aren't logged or saved. The post might exist in the backups Sirius and Gavin keep.
|
|
|
Because the problem that they are trying to solve in privacy for the individual surfer, and if everyone knows the password, anyone can still see everyone else's packets. Tor is a good solution, but so is a private VPN to connect to. These are good practices anyway.
WPA uses separate encryption keys for everyone, so you can give out a password without allowing people to snoop on your traffic. This is not the case for WEP.
|
|
|
-rescan is apparently broken for 0-confirmation transactions. In cases where a 0-confirmation transaction gets stuck, you'll have to delete the block database files. It'll be obvious when this happens.
|
|
|
Yep. That's Luke-jr's pool. Puddinpop's pool also used to do that. It's nice because all participants get paid immediately instead of having to wait 120 blocks.
|
|
|
|