* Fees do not prevent an attacker from spamming. A determined attacker will simply use a different client. By putting this ineffective measure in the official client, we only punish legitimate users.
Please direct me to this other client that can cause other nodes on the network to accept and relay my fee-less spam transactions.
|
|
|
Sempron 140 or Socket 775 Celeron D.
The Sempron has a TDP of 45 watts, while the Celeron is only 35 watts. However, you can get boards with AM3 sockets that have 6 PCIe slots. I think if you want that many slots on an intel board, you are looking at a much higher power CPU.
|
|
|
It is too late. You will never get the network to agree to changing the fundamental unit. Let me repeat that never. For this to work, you would need to shut down the entire network, at once, for the big software update. Will. Not. Happen.
Feel free to set up your local display for whatever floats your boat, but if you use the term bitcoin to mean anything other than what the rest of the network thinks of as a bitcoin, you are in for a rude surprise.
|
|
|
PCIe x1 is fine for mining.
|
|
|
Get .bit included in the root servers and I'll become interested. And so will everyone else.
|
|
|
The fee system is strange, and not very transparent. It will probably improve soon.
When you try to spend, your client gathers smaller amounts from your wallet to total more than you are trying to spend, then sends the amount you want to send to the recipient, and the change to a new address in your wallet. The more transactions it has to gather, the bigger the block will be. If the block is large, and the transactions are low priority (age increases priority), it will attempt to include a fee.
Other nodes also check incoming transactions, and they may refuse to relay your transaction if it is large (in bytes, not coins) and/or low priority and doesn't include a fee.
Nodes and miners are free to change their own local rules for accepting and relaying transactions, but this isn't currently easy since it involves recompiling the client, or using an alternative client. Again, this will be improving soon.
|
|
|
If you think any of those options is easy, I'd hate to see what you think is hard.
|
|
|
Section 2, misunderstanding of how the network works, particularly in regards to relays. Explained earlier.
Section 3.1, a spender looking to send a transaction with a fee big enough for you to care will be well connected. 80+ connections is trivial today.
Section 3.2, some of those limits are hard, and some are soft. There is nothing to suggest that any other value for the hard limits would be any better than the ones we have. The soft limits can be (and have been) changed as the network evolved.
Section 3.3, those developers are actively helping other people create alternative implementations of the software. The developers all understand which limits are hard and which are soft. What is your excuse for not having researched the matter? Any hardcoded checkpoint blocks that are not in agreement with the rest of the network will prevent those implementations from catching on, this applies equally well to new versions of the original client as it does to upcoming alternatives.
Section 3.4, pruning code already exists. It is not widespread because there is no need for it yet.
Section 3.5, I'm sorry you don't understand the script system. It isn't a vector for malware infestation, and probably never will be because it only supports a small number of cryptographic and mathematical functions.
Section 3.6, we all knew that unconfirmed transactions were unsafe before you arrived to show us. Your notion of nodes forgetting transactions, however, is pretty silly. Even more silly is that they have to forget them in such a way that they remember not to get them again when another node offers.
Section 3.7, I'm sorry you showed up too late to the party. For what it is worth, I did too; I have around 10 coins to my name. I also observe that the universe doesn't give a fuck what you consider fair, and neither does anyone else.
The rest of your proposal is harder to dissect because it consists of a series of conjectures with no evidence backing them up. Here are the highlights.
Sections 4.1 and 4.2, storing balances instead of transactions won't give much space savings. Addresses are no more limited than transactions, unless you think you have some way to limit each person to one address.
Section 4.3, I LOL'd. Hint, the hard part is mining, not pushing transactions around.
Section 4.4 is madness. The chain will reshuffle thousands of times each day.
Section 4.5 why the hell would anyone care how many hashes you did? Are your hashes valuable in some way? In bitcoin, there are answers to these questions, and those answers are critical to the functioning of the system.
Section 5, Conclusion. You don't understand any of the important decisions that went into the design of bitcoin. Either that or you are a very special kind of troll.
Edit: Oops, section 3.6, changed safe to unsafe
|
|
|
I guess it might be possible to create a unit of absolute value. But the price of everything in relation to it would always be shifting.
|
|
|
Are you aware that no one really owns land in the US? What they really own is an interest in the land. And you can totally take someone to court over violations of interest in something you don't own.
So, no, copying the wallet file is not theft. But if you then deprive the real owner of their interest in the bitcoins controlled by the keys in that wallet, you will find yourself in court. (Assuming that the victim knows where to find you.)
|
|
|
You could pay someone to make a new client, or to make a patch for the default client. Bounties have been popular.
The point is that changing your local client to display mBTC or uBTC, or to allow switching between them, doesn't require that the entire network change instantly.
|
|
|
Join a pool. You will likely never find a whole block by yourself, particularly not with that setup.
|
|
|
If you already have the case, PSU and flash drive, you can put together a single GPU box for about $100 + the cost of the GPU.
Used case with a crappy 250 or 300 watt PSU, a Gigabyte G31M-ES2L with a Celeron D CPU and some cheapass RAM. The CPU only draws 35 watts max, so you can easily fit a 200 watt GPU onto whatever power supply you already have.
And if you have a bigger PSU, you can use a PCIe extender to hang a second card off it.
|
|
|
There are no actual bitcoins. It is just an arbitrary unit of accounting. Currently, we are capable of dealing with transactions down to 0.00000001 BTC, and can expand lower if necessary.
|
|
|
Someone just moved 6.5% of all bitcoins in existence. I don't think that any person or company has control over anywhere near 6.5% of the world's dollar market.
|
|
|
You don't think that maybe the relative sizes of the two currencies might have some bearing on the relative volatilities? Like maybe since the dollar is used by everyone all around the world (more or less) it might take more effort to swing it than a very recently invented currency used by a few thousand people?
|
|
|
I agree with the op, that the decimal place should shift.
Perhaps this only needs to be a client UI issue tho - all transactions could still use the current decimal places, and just in the UI the user could switch between 'BTC' i.e. what we have now, or a more user friendly 'UBTC' or whatever we call it, which makes them feel richer and is perhaps easier to use in mental math, etc (and which is perhaps the default 'view').
just a thought
*edit* just did some reading, looks like others have already suggested just making it a simple client ui edit. seems the easiest way to go.
This is the only renormalization that is even remotely practical right now, and there is nothing stopping anyone from implementing it locally.
|
|
|
|