|
I like using "pronounceable password generators" to come up with names for things. I just go through the results and pick one that sounds good, oftentimes modifying it slightly.
|
|
|
|
|
With a 10MB limit, someone can create 10 full blocks within a 500-block span to disable getblocks uploading for almost the entire network. This is probably an even more effective attack than whatever the limit is designed to protect against.
|
|
|
|
That was a few days ago. 1AYtn... received 400,000 BTC and then sent 150,000 BTC to 1LYJH... (possibly the same person). 1LYJH proceeds to break the coin into many smaller pieces over a long period of time. My guess is that 1LYJH is breaking the coin intentionally for some reason (maybe anonymity). There might also be another person ( 1NMDH) between 1LYJH and the chain of coin-breaking transactions. Interesting series of transactions. One of the 400,000 BTC transactions was only 259 bytes in size, and only one transaction/block, since the 400,000 BTC was already in one coin. |
|
|
|
|
Couldn't peers theoretically need to send 500 MB in response to a getblocks request? The limit should perhaps be MAX_BLOCK_SIZE*500.
|
|
|
|
|
Many sites nowadays require that your browser send the correct "host" header ("Host: mtgox.com") so multiple sites can be hosted on one IP address. This is why you often need to put the name in the hosts file.
|
|
|
|
Ha, now it's reversed: mtgox.com works and www.mtgox.com doesn't work. You need to explicitly add the www.mtgox.com name to your hosts file. It doesn't work recursively. |
|
|
|
Ok, I'll try, but how much does speed increase? 0.01 = 10 minutes? How does it work?
A 0.01 fee per kB should almost always get your transaction into the next block (in ~10 minutes). |
|
|
|
|
That's pretty bad. Good thing you caught this before everyone upgraded and new nodes were no longer able to connect.
|
|
|
|
I changed the help text to hopefully make it more clear: If this output has ever been spent by the recipient, the transaction that did it is listed here. |
|
|
|
Those superscript question mark links on Bitcoin Block Explorer produce help text when you hover your mouse cursor over them. If this output has ever been redeemed, the transaction that did it is listed here. Whenever you spend coins, you redeem one or more outputs. The output is attached to an input in the new transaction you create, and you create a new output that will be redeemed by whoever you send the coins to. output -> input -> output -> ... See https://en.bitcoin.it/wiki/Transactions for more info. |
|
|
|
|
I like SMF. What is it missing?
|
|
|
|
|
I think Jed is a good, honest administrator. He's eaten a lot of costs, even though he probably makes very little money from the site. However, I have never trusted the software or concept of MtGox, and I will never store loads of money there.
|
|
|
|
|
Smutfairy.com is an IRC server for irc.lfnet.org. It's safe.
|
|
|
|
I'm looking for a way to verify if the current getwork I'm on is from the current, or last block. Would I be able to do that by looking at "prev_block", and checking against a stored array of the "prev_block" from the previous two blocks?
Like, I have an array with the two last known prev_block values in it. If the prev_block value from the getwork matches the newest stored prev_block value, I know it's from the current block. If it matches the oldest prev_block value, it's from the block prior to the current. Correct?
That won't work unless your getwork is putting you back to a block you've already seen, which it shouldn't do. The problem is getting the hash for the most recent block, which you have never seen before. If you only need to get this data once in a while, you could use this: http://blockexplorer.com/q/latesthashOtherwise, you could patch your Bitcoin to support jgarzik's getblockbycount and then combine getblockbycount with getblockcount to get the hash of the latest block. If you have access to Bitcoin's debug.log, you can search it to find the latest block hash. |
|
|
|
That seems fair for a default fee rule, though nodes should ignore all fees when relaying. When I complained about the introduction of that particular code on the forum, Satoshi asked me to stop talking about it due to a DoS risk. He seemed to think the risk was pretty serious. This makes me think there might be some hidden DoS vulnerability we don't know about. This was when clients were still waiting for a block number to change the rule, though, so it might have been just the transitioning that caused the vulnerability. The thing you highlighted is a patch for a DoS
weakness. I don't want to post an instruction manual for how to use the
weakness to DoS the previous versions.
I think most P2P networks, and websites for that matter, are vulnerable
to an endless number of DoS attacks. The best we can realistically do
is limit the worst cases. (I'm absolutely in favor of the feature -- I just want to mention Satoshi's view.) |
|
|
|
Probablythis is the Faucet.
It could also be the pool, which sends many little transactions that are dependent on each other. Ideally it would send them all in one transaction. It goes without saying that a tx can't go in a block if it's predecessors are not in blocks.
The protocol allows for a transaction and its predecessor(s) to be in the same block. The priority mechanism just prevents it from ever happening (for miners running mainline Bitcoin). |
|
|
|
|
The transaction in 170 was from Satoshi to Hal. Satoshi must have done all his testing beforehand.
|
|
|
|
|
A topic like this seems to appear once or twice every week.
|
|
|
|
I disagree. You cannot change that without vastly increasing the ability to spam the network with useless transactions.
Having a memory pool size limit where transactions are removed based on priority would solve that, I think. Enabling the -limitfreerelay switch by default might also help (with lower minimum fees). |
|
|
|
|
Show Posts
