|
Someone was sending the same ~95000 BTC repeatedly. He could have gotten the "daily sent BTC" to 22 million if he kept it up.
|
|
|
|
|
It's to encourage you to switch addresses often, which improves anonymity.
|
|
|
|
|
It creates a new address whenever the current one receives a transaction.
|
|
|
|
|
Some semi-separate network will probably be created eventually to anonymously find transactions to yourself and get Merkle branches. Then there's no point in having a "get the full Merkle tree of this block" message, though. I can't think of any situations where this message would be useful.
|
|
|
|
|
I'm not sure that there would be any point to providing Merkle trees through a separate message. You need to download full blocks to detect transactions to yourself, anyway.
|
|
|
|
The scriptSig of the generation input is changed when the nonce overflows, which changes the Merkle root. "Bits" expands to a 256-bit target number, which the hash must be below. Current target: http://blockexplorer.com/q/hextarget |
|
|
|
The transaction is invalid because the input 913d37f326 was already spent. This probably happened because you were running two installations with the same wallet, or you did some other strange thing with the wallet. Some of those inputs are now tied up with a transaction that will never clear. You need to remove the transaction. If you have a wallet backup, delete the block database, restore from the backup, and see if that removes the transaction. (Make sure your balance is accurate.) |
|
|
|
There are multiple transactions showing up which have a combined size of 94600 BTC.
Is this a double-spending attempt or does someone actually have multiple chunks of 94600 BTC?
They're the same coins. |
|
|
|
|
With network segmentation, blocks will be produced more slowly. There will also be a large reorg after the network recombines, which is detectable.
|
|
|
|
|
The ones with 8333 at either end of the connection are.
|
|
|
|
Wait, are you saying MtGox is hosted in Japan? I though that the founder was from New York State.
The original owner was located in the US, though he moved to Europe. MagicalTux now owns it from Japan. |
|
|
|
|
See anything relevant in debug.log?
|
|
|
|
|
It only adjusts every 2016 blocks. If we get stuck in that kind of situation, the code will probably be changed to allow for difficulty reduction in some other way. I think it's unlikely we'll ever get that stuck, since transaction fees will accumulate until blocks become valuable enough.
|
|
|
|
4) Bitcoin uses IRC, so an ISP would have to block IRC to stop it.
Bitcoin doesn't use IRC for communication. It uses TCP over a fixed port, which makes it very easy to block. You can use Tor to bypass this, though. |
|
|
|
|
There is a .lock file in the data directory, though I don't know how reliable this is. Maybe it only appears when Bitcoin is doing something to the database.
You could parse /proc/net/tcp.
|
|
|
|
The point here is to validate ownership of names, not restrict the total number of names or in the system to an arbitrary upper limit, right?
If so, would it be possible to tie in the difficulty of the proof-of-work to be based on the number of new name requests seen in the past two weeks? That is, the more requests, the easier the difficulty of hashing a block, and the more quickly blocks are generated? POW would also obviously have to be tied into the amount of processing power being thrown at the network as well.
There's a lower limit to the number of minutes between blocks. Below that, latency plays too big a factor. So you'd want to adjust the block reward and block size instead of the block frequency. That would probably result in prices going too low, where there are more domain requests than the network is actually capable of fulfilling. Supply/demand can't be calculated automatically: there needs to be a market. If a separate chain is used, miners need to sell domain space. I'd just put the data in the Bitcoin chain and rely on Bitcoin's transaction fees, though. |
|
|
|
if curl -s 127.0.0.1:8332 >/dev/null; then
echo "running"
else
echo "not running"
fi Edit: Another way (faster): if /sbin/ss -l |grep -q "127.0.0.1:8332"; then
echo "running"
else
echo "not running"
fi |
|
|
|
(and while we're at it, can we move ~/.bitcoin to ~/.config/bitcoin to avoid cluttering the home directory? >.>)
You can change the location by running Bitcoin with -datadir=~/.config/bitcoin or whatever. |
|
|
|
|
Spam = transactions made for the purpose of disrupting the network.
|
|
|
|
|
Show Posts
