You must have received a ton of very small transactions. As a result, sending them all requires a lot of data. The fees are usually not so high.
|
|
|
It's to make the public keys shorter. You could just truncate the key and say that any key with the same start is OK, but this is probably less secure than hashing the entire key.
|
|
|
Forget for a while about transaction fees, but can one of these transactions be pruned (after being confirmed by enough blocks in the longest chain)?
The first one can be forgotten (assuming it only has one output). It will never again be needed for verifying other transactions, since it can't be redeemed again.
|
|
|
Is it possible to have a decentralized pool, or is a central authority required to ensure miners are honest?
It is possible to have a decentralized pool, but IMO building it would be a waste of time, since it will be too expensive to be a full Bitcoin node not too far in the future, and participants in a decentralized pool must be full nodes. A decentralized pool also requires a great deal of bandwidth itself, since all peers must understand the complete state of the pool (as far as I can tell). One possible design: - Each miner broadcasts all of the low-difficulty shares they win, which is used to calculate proper ratios for every participant. - Each miner works on its own block. The coinbase transaction pays out according to ratios that it calculates. Each miner chooses which transactions to include according to its own rules. - Miners broadcast their block headers, coinbase transactions, and Merkle branches for their coinbase transactions to the entire pool. The pool doesn't need to know which other transactions they include. - When you receive a header+coinbase, you examine the payout ratios, and if you agree with them, you add the person who sent it to your own coinbase transactions for payout.
|
|
|
I'm not sure that there will be a sufficient market. I hardly ever send snail mail.
|
|
|
The active administrators are currently: theymos (me) Gavin Andresen sirius
Sirius runs the server.
|
|
|
No. The demurrage fee will be charged only if the network agrees, but miners can forget transactions without asking permission. This was an argument against the need of demurrage fees. Most miners will forget old transactions, and only "archivers" (specialized miners) will get the fees for transactions that contain an "old account" as input.
I argued against that notion in the thread: If miners with your rules don't have >50% of the network, you can't safely forget unspent transactions. If you are unable to find the transaction when it is needed for verification, you have only two bad choices: - You can accept the transaction without checking it after it gets in a block. Every time one of these blocks ends up getting rejected by the majority of the network due to its invalid transaction, you will lose all of your hashing work since the last block. (This is even worse if you wait a few blocks before accepting it.) - You can reject the transaction. Some important part of the network might accept the transaction, and you will be isolated from them unless you have more than 50% of the network.
|
|
|
But in the demurrage fees thread has been said that miners can forget transactions even if they're not spent.
That's only if >50% of the mining power agrees to do that. I doubt it will ever happen.
|
|
|
Right now only technical people can use Bitcoin, and most technical people are male for some reason. Once Bitcoin (or some EWallet service) is easy enough for non-techies to use, it will be adopted by some communities that contain a balanced or female-dominated demographic.
|
|
|
You need to tell your shell where the bitcoin binary is located. It varies by distribution, but you might try: /usr/bin/bitcoin -addnode... or or Use your file search utility if none of that works.
|
|
|
I think my largest trade for real-world items was 300 BTC for a laptop.
|
|
|
I'm not surprised. MyBitcoin is still accepting payments with only 1 confirmation, which would allow some of the larger pools to steal BTC right now.
|
|
|
"Elegant" is word that describes the core of Bitcoin well. Maybe a few things could have been done better, but the current system could conceivably work for hundreds of years (with minor tweaks along the way).
|
|
|
An output with 0 value is valid, and these outputs can't be forgotten by the network until they are spent (which is also valid). So you can stuff all of the DNS data into several of those outputs.
When the bitDNS spec was written, having more than two outputs was not considered standard; therefore, it was difficult to get those transactions into blocks. Now they are standard.
|
|
|
BTW, Luke-Jr pool accepts transactions with lower fees... I can't seem to figure it out though, I added "-addnode=173.242.112.53" when launching Bitcoin but it still forces the 0.01 fee. Must be too late at night for me.... Your client doesn't negotiate fees in any way with your peers, so it doesn't know that Luke-Jr requires lower fees. You have to modify your client (or use an old version) to take advantage of the lower fees. Luke-Jr also rejects all totally free transactions, I believe.
|
|
|
As most miners will forget old transactions, you would have to renew the transactions from time to time with BitDNS. Am I right, theymos?
Yes. Our spec handles this by requiring DNS renewals. There are ways to handle it more elegantly, though (using multiple 0-value outputs, for example). The spec was written a while ago.
|
|
|
No one will accept your reversible credit card or PayPal money for non-reversible bitcoins unless you prove your trustworthiness in some way. The difficulty of trading isn't a problem with Bitcoin (mostly): all non-reversible payment methods such as wire/ACH transfers are just difficult to use, and you need to use them to get bitcoins.
Pecunix is 9 years old, but it still has this problem because it is also non-reversible. In fact, Pecunix is probably even more difficult to get. Same for Liberty Reserve, though it is younger than Pecunix.
|
|
|
You can set the fee in the options or is that something else?
That can only increase fees from the default, not decrease them. Once transaction replacement is possible, Bitcoin will hardly even have to worry about this. People will use trial and error to find the correct fees.
|
|
|
Currency Exchange Goods Services Employment
Someone make it happen. If I want to buy chicken bones first I have to see if any are for sale, then I have to go to a different forum to offer to buy them. What the hell? This applies for everything, not just bones. If I'm just curious about what goods are being bought and sold, I have to go to two forums, why?
The current setup is not good for users at all. It's simple to police, that's it's only benefit.
I'm going to repost this in it's own thread later if I need to.
This sort of split makes more sense to me than "buying/selling". Shouldn't "employment" be combined with "services", though?
|
|
|
|