|
The Faucet sometimes silently delays payment as an anti-abuse measure. It'll probably send the coins eventually.
|
|
|
|
That's not at all relevant to the issue at hand. It's easier to understand "newly-generated" than "pulled from the keypool". In that same thread I agreed that the keypool is used for generations: ah, theymos, you're here - so what about the key pool? will the 'looking at wallet backup' thing work?
Yes. It's good for 100 generations (and you can use the -keypool switch to increase this). |
|
|
|
I suppose the amount could be any amount (e.g., just 0.01 BTC) as long as I've emptied my wallet (down to 0 BTC) first.
Emptying your wallet would also work, but if you create an output with the exact value that you will use for an input, Bitcoin will choose that specific output to use for the input, and it'll use the correct address without having to send everything. |
|
|
|
|
I prefer the official logo over skull88's logo.
|
|
|
|
|
You could create a new address, give that to the merchant, and tell them an exact time at which you will transfer from the address in question to the new address. You can cause Bitcoin to send using a particular address like this:
- Send some unusual amount (like 54.37) to the address in question.
- Wait for 6 confirmations.
- Send that same unusual amount to the new address.
(You might have to do this a few times before Bitcoin chooses the right coin, though I think it will usually pick the right one.)
|
|
|
|
Looks like we have a very smart 10-year-old here.  |
|
|
|
You might be able to hard-link the blk0001.dat and blkindex.dat files, but I don't think that's been tested at any point. A shell script to switch around the wallet.dats might work better.
That's going to cause a lot of problems if you don't run Bitcoin with -rescan all the time. |
|
|
|
|
You could probably do it if you always run Bitcoin with the -rescan switch.
|
|
|
|
There's no documented way to make it synchronize more than once a week
It is documented: http://technet.microsoft.com/en-us/library/cc773263%28WS.10%29.aspxYou need to change this registry value: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\NtpServer Change the server flag from 0x9 to 0x0. Then you'll update using "smart adjustments" like normal NTP clients. You could also instead change W32Time\TimeProviders\NtpClient\SpecialPollInterval to update more frequently. |
|
|
|
I completely disagree. The more nodes which are connectible the harder any kind of Sybil attack becomes which just benefits the network. Any user who has a legitimate reason why they don't want incoming connections will already either have UPnP off on their router or be able to disable it in the client.
Think of all those users in Canada and Australia who will have their limited bandwidth siphoned away without any warning... After Bitcoin runs in lightweight client mode by default, it would make sense to ask the user about triggering UPnP if they enable "supernode" mode. |
|
|
|
|
It should not be enabled by default. Opening 8333 significantly increases network usage without any benefit to the node.
|
|
|
|
Ah, so it isn't something that anybody could easily do to make sure they didn't type in an address that was not valid.
You can use this to do the same thing: http://blockexplorer.com/q/checkaddress |
|
|
|
Because it's profitable. Someone could build an unsafe building but sell it for the greater price of a safe building. To that person, the short term benefits make up for the long term costs.
That person is guilty of fraud, and will be boycotted by everyone forever. It's a very bad business decision. I'm not saying that no one could make such a decision, but they will be quickly eliminated from the market. |
|
|
|
|
Maybe it's a bug. Getinfo should return your actual balance. Can you send the full 0.13? What's the address you received on?
|
|
|
|
I would argue that it would be valuable to have finer-grained confirmations for the sake of speed. In a point-of-sale situation, for example, being able to confirm a small transaction quickly is very important.
0.01 of a confirmation on your network is actually worse than 0 confirmations on the Bitcoin network. With 0 confirmations you are protected somewhat by the TCP-level network, but anyone can reverse a transaction with 0.01 confirmation, overruling the TCP-level network. Can you elaborate on how it hurts scalability? Isn't it all the same data being passed around?
It's a lot more data that lightweight clients will have to download. There's an 80-byte header per block that clients need. If this was required for every transaction, then lightweight clients would have to download about 17MB more data currently. This will become a lot more significant as the number of transactions per block increases. Also, if you have multiple "previous block" hashes in each transaction, you'll need headers that are much larger than 80 bytes. Normal clients will quickly lose the ability to send transactions. |
|
|
|
|
Why would anyone make buildings that will be destroyed by earthquakes? That's a massive loss of money. Construction companies would lose all reputation if their buildings can't withstand expected local conditions.
|
|
|
|
|
That doesn't help much. You need to wait until your transaction is buried deep enough in the chain for an attacker with less than 50% of the network's computational power to be unable to reverse it. If there are many smaller, easier blocks, you'll just have to wait 300 confirmations (or whatever) until that target is reached. In other words, you always must wait for the network to do a lot of work after your transaction.
It would provide more fineness in desired confirmations; you could accept transactions with 2.5 Bitcoin-equivalent confirmations. But it's bad for scalability, and the increased fineness isn't valuable, IMO.
|
|
|
|
|
Probably you didn't use "sendfrom" when sending, so the balance of the account wasn't reduced.
|
|
|
|
True, but why the hell it requires all those widget and X libs.
bitcoind doesn't require wxwidgets. The GUI isn't built when you compile bitcoind. |
|
|
|
|
Show Posts
