|
You only need to do it once if you don't need the pool to re-fill to that level.
I wonder if that many keys will slow Bitcoin down. I believe wallet.dat needs to be stored entirely in memory, so it will at least increase memory usage.
|
|
|
|
|
People will do it anyway with bots, so I don't see any reason to remove it.
|
|
|
|
Is there a contingency in case Blockexplorer is down?
Hopefully BBE will not ever be down for too long, but you can get the same information by looking at the blocks locally. One way to do it is to output all getblock dumps to a single file and search this file for all instances of the lotto's address in hash160 format. |
|
|
|
|
The minimum bid interval is too high.
|
|
|
|
how does it originally work?
Here is the version in the current release: // Limit free transactions per 10 minutes
if (nFees < CENT && GetBoolArg("-limitfreerelay"))
{
static int64 nNextReset;
static int64 nFreeCount;
if (GetTime() > nNextReset)
{
nNextReset = GetTime() + 10 * 60;
nFreeCount = 0;
}
if (nFreeCount > 150000 && !IsFromMe())
return error("AcceptToMemoryPool() : free transaction rejected by rate limiter");
nFreeCount += nSize;
} The effect of this is that the entire network starts rejecting free transactions at the same time. The latest Git version of limitfreerelay (now enabled by default) has a better method for deciding when to turn off free transactions, but the entire network still turns it off at around the same time. This is bad because a constant spam attack will make it impossible to ever send a free transaction. By blocking per IP address instead of globally, it's more difficult for an attacker to do this. |
|
|
|
How fast are these spams? could putting a limit of one send transaction per minute help?
That's what limitfreerelay does (though this is disabled by default in the latest release). I'm proposing to apply it per IP so an attacker can't turn off free transactions over the whole network so easily. |
|
|
|
I'm not clear what you mean by "transaction spam."
People sending 0.01 back and forth to attack the system. |
|
|
|
i'll try it with -maxconnections=16, see if i can get more peers.
That will reduce the number. Maxconnections is the maximum number of total connections -- additional incoming connections will be rejected. (I also made this mistake for a long time.) |
|
|
|
|
Good talk! You covered some of the more inspiring aspects of Bitcoin. I especially liked that you mentioned the genesis block headline.
You said that mining is unprofitable, but it is quite profitable for GPU miners.
|
|
|
|
|
Doesn't work on Firefox, either, unless I enable scripting.
|
|
|
|
Wouldn't that make free services like mybitcoin blocked by their neighbors unless they paid transaction fees?
With the current limitfreerelay system, they'd be blocked anyway, just network-wide instead of locally. |
|
|
|
|
Spamming "addr" messages is not very effective because your immediate peers will not broadcast addresses that they've already seen before. They create a "wall" around the spammer. This would be a nice feature to have for transactions, as well.
Implementation seems pretty simple: "limitfreerelay" restrictions would not apply to all transactions, but only on a per-IP basis (and maybe also by larger IP blocks). The spammer would be blocked by all of its immediate peers after sending the spam, creating a "wall". These peers would be blocked by some of their peers (only those who first received the transaction from the peer), etc.
The result should be that only the spammer's "neighborhood" of nodes ends up blocking free transactions. Most of the network still accepts free transactions. This makes saturating the network's free transaction relay allowance much more difficult than the currently limitfreerelay system.
|
|
|
|
Theymos, I understand where you're coming from--but saying miners create coins is exactly like saying that printing presses create dollar bills.
That is what I would say... The bills are created by printing presses. They're given value by the people. Can you clarify one thing for a n00b? I was given to believe that while yes, miners generate the blocks, the blocks are validated by every user that stores a copy of the blockchain. Is that incorrect?
This is currently true, but in the future almost everyone not using an EWallet service will be using simplified payment verification. With this, you rely on confirmations to verify transactions and blocks, and confirmations are made by miners. If one collection of "allied" miners has more than 50% of the network, and they give themselves higher block rewards than are allowed, SPV clients will accept these transactions. Additionally, if bitcoin.org releases a version of Bitcoin with different block rewards, miners could block the change even if most Bitcoin users switch to the new versions. The people using this new version rely on miners to defend them, so changing the block reward to 0 will not work even if every non-miner moves to the new system. The system will have few miners of its own, and miners on the old system will attack the new system to make it unusable. Everyone will have to either move back to the old system, make a new system with rules that the miners will accept, or abandon Bitcoin. The "payed by the network" terminology is fine for explaining the effects of coin distribution to newbies, but it's confusing elsewhere. |
|
|
|
Can that -maxconnections= only be changed using bitcoind?
No, it also works with the GUI version. |
|
|
|
|
Users don't create coins. Miners do all the work: they do the difficulty adjustments, they create blocks, and they verify other blocks. A network with no users other than miners would still generate coins. A network made of just one miner would still generate coins. Users certainly give these coins value, but the miners create them.
Bitcoins are imaginary, and this aspect of the system is important. They were not created "mathematically" at the start. You can change the end total number of bitcoins by adding just a single "0" to the code that determines block value. These new coins would be worthless, of course, but they would still be created.
Real-life example: Due to a bug, billions of bitcoins were created in one transaction. These coins were recognized by the entire network for a while, even though they were not taken from some "global pool".
|
|
|
|
What screen resolution are you referring to? It works from 995px wide screens up to >1500px.
It causes a horizontal scroll bar to appear on the width I keep my browser at. The navigation menu is barely visible on 800x600. |
|
|
|
It looks nice, but it's too wide. |
|
|
|
You'll send double the number of addr messages, which could help addr propagation slightly. Sending more addr messages has diminishing returns, as peers around you will block your duplicate messages. The main bootstrap method is IRC, though, and having two nicks on IRC doesn't give you any advantage. In any case, it won't cause any problem for you or the network, aside from unnecessary resource usage. Second, if I have the NAT'd client connect to another client on my local network (e.g. 192.168.*.*) won't the client see that as an invalid address and do its normal thing anyway?
No. |
|
|
|
|
Miners do generate coins. If all miners stopped mining, then no more coins would be created.
|
|
|
|
|
Show Posts
