|
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.
|
|
|
|
|
As I said in the BitDNS discussion, hard-limiting the network-wide number of registrations will fail. If 50 domains are produced per block, then what happens when more than 50 domains are needed per 10 minutes? Prices will become uncompetitive and the system will lose popularity.
|
|
|
|
|
Tying up funds makes it more difficult for an attacker to spam. Spamming 1000 BTC transactions is more difficult than spamming 0.01 BTC transactions.
|
|
|
|
It was given lower priority because of its low value. A transaction moving, say, 1000 BTC would probably have gotten included ASAP. Same for a transaction with a fee. The priority system is meant to make real transactions faster than spam transactions. Sending 0.03 BTC looks more like spam, especially when you use inputs with relatively few confirmations. If the transaction fee is set to 0.00 anyway, then what's the incentive for a miner to process higher value transactions?
There's no obvious incentive for processing free transactions at all, but miners still do it currently. Higher-value transactions are given priority because it ties up more funds. |
|
|
|
|
Sometimes it takes a while, especially if the transaction is low-value.
Run Bitcoin with the -debug switch, double-click the transaction, and post the transaction dump.
|
|
|
|
|
See if deleting everything in the data directory other than wallet.dat helps.
|
|
|
|
I believe Satoshi was working on this idea for quite a while...looking at the code, I don't think this was something he threw together in a couple months. I think he may have been working on it for several years and took great pains to ensure it was sufficiently evolved such that it wouldn't simply die shortly after its release.
He said he was working on it since 2007. |
|
|
|
|
The dependencies for bitcoind are themselves pretty easy to compile.
|
|
|
|
|
Until Bitcoin gets user functionality, I think it'd be best for each user to run his own instance of Bitcoin running with "-connect=127.0.0.1 -nolisten" to connect to the one network-facing process.
|
|
|
|
ICANN is not an American company.
A California Nonprofit Public-Benefit Corporation |
|
|
|
If there was a problem with the inputs (already spent eg.), the correction tx won't be accepted either (and you definitely don't want a correction tx for a correction tx).
Bitcoin can cancel one input per day until one of the cancellations goes through. |
|
|
|
|
Smart people will launder their coins before anyone has a chance to freeze them.
|
|
|
|
If we do need to change bitcoin's precision in the future, will it be possible?
Yes. As long as everyone agrees to the change, it will be slowly phased in over years and there will be no problems. If this ever becomes necessary, we'll all be so rich that we'll be able to hire teams of people to worry about it for us. |
|
|
|
|
Show Posts
