|
If you already redownloaded after the problem developed, then doing it again probably won't help. You can't have gotten a bad copy, since Bitcoin checks the blocks before adding them to the database (unless you manually replaced the files).
|
|
|
|
|
You also need to delete blk0001.dat and blkindex.dat. I think this is a rescan bug.
|
|
|
|
So what is the advantage beyond simply publishing your public key? Which is already an address?
Satoshi's proposal doesn't make that much sense either. If you use <key>.<IP> the entire shortening advantage goes away.
And IPs can change if you move providers, or if your provider moves IP ranges, so they're also not useful as long-term address to publish.
Addresses are not public keys. Addresses are public key hashes, which necessitates a larger transaction (24 bytes extra per output). As I said before, the main benefit is sending messages out-of-band. I never even mentioned shortening as a benefit... You should be able to use domain names instead of IPs. (I know you can't right now.) IP transactions is one of those things, like script, that will probably have some interesting uses later. Unlike address transactions, the recipient can refuse a transaction before it's even made (if the input is wrong, for example). This would solve the refund problem that some merchants have had. It's also one way that lightweight clients might receive transactions without checking the block chain. I'm fine with hiding it from the "send bitcoins" UI for now. |
|
|
|
1) I don't believe that secure IP-based transactions are possible. The internet has no API to confirm that you are the real owner of an IP address. This would need to involve your ISP.
You publish a public key along with your IP address. 2) We already have bitcoin addresses, why would you complicate it by having mulitple kinds of addresses? What inherent advantages do IP transactions have that hash-based transactions don't have?
You can send a message without putting data in the block chain. IP transactions are also more size-efficient, and they might be used as a base for "user@domain"-style transfers. 3) Also if you really want IP based transactions (or other forms of address shortening) they could be implemented as a secondary service apart from the P2P protocol. I see no advantage to having this as part of the main protocol.
It basically is a separate protocol now. It's not required to implement IP transaction functionality if you're making a client. Care to give a pointer?
The current sending by IP is not very useful: it connects to the IP, so you'd like to use TOR for anonymity, but then it can totally be eavesdropped and man-in-the-middled.
The future plan for sending to an IP is to make it a bitcoin address plus IP, like:
1auaDZCFYqaGx4FKS5WenNfurk2SkoDu4h<someseparatorcharacter>1.2.3.4
or
1auaDZCFYqaGx4FKS5WenNfurk2SkoDu4h<someseparatorcharacter>domain.com
I need suggestions for the separator character. ":" is a candidate, but IPv6 has : in it and that might get confusing. Something that's allowed in url parameters would be nice.
I want to use SSL for the connection, using the bitcoin address' public key as the cert. You would be certain you're connected to who you thought, and safely encrypted. The bitcoin address would not be used for the transaction, only for authentication. A new generated bitcoin address would be sent through the SSL connection.
Since it's authenticated, it would then be safe to allow the IP address to be a domain name. Some care taken that if a proxy is used, it uses socks4a instead of DNS lookup.
|
|
|
|
|
Why not implement the secure IP transfers that Satoshi talked about instead of removing it? I've always thought that IP transfers would be very useful if made secure.
|
|
|
|
|
The minimum target is slightly off from 2224.
A block with a hash equal to the target is also valid, so the real max difficulty would divide by zero.
|
|
|
|
|
It'll detect the transfer from the keys that you do have. If there was no transfer from the keys that you do have, then you'll still have that BTC.
|
|
|
|
So i backup my wallet, use up my keypool by sending 100 small amounts of coin, then on the 101th transaction, i send my remaining balance somewhere, say 100 coins. I then restore my backed up wallet, since it has no key for my 101th transaction, it should restore my balance to 100, right? Thats what is confusing me, obviously this can't be the case.
It will detect the new transaction and set your balance to zero. However, if that 101 st send did not empty your wallet, you would lose some random amount of additional BTC beyond what you sent. After 120 sends, you'd probably lose most/all of your BTC. |
|
|
|
|
Maybe laszlo can set it up so that no one can be an op in those channels.
|
|
|
|
|
Block collisions would break the system, since people would have different ideas about which blocks are which.
|
|
|
|
|
I'm not necessary opposed to the idea of a currency exchange subforum if it is needed, but I am opposed to creating it just because "buying/selling" is ambiguous. If it is created for that reason, then you'll be able to argue that every trade type needs a new subforum, since everything will be ambiguous.
|
|
|
|
|
Block hash collisions would be a more serious problem than difficulty limitations if we ever got that far, since only one block can ever be produced at the max difficulty: all other blocks would be seen as duplicates of that block.
|
|
|
|
I get it now. The 100 keys you have are only needed for receiving money, not sending money. I mistakenly thought that you used up your keys for spending coins, but obviously that is not the case. Each amount received is tied to a certain key, if that key is not in your wallet, the network will not recognize that amount in your total account, and adjust accordingly. Therefore it is critical you maintain a list of ALL keys you have ever received money on.
You've got it backwards. Each send creates a new key. You can receive as many transactions as you want and not use up any keys. |
|
|
|
Yeah, that will improve things!  I think it will, since you can more easily ignore certain people and the barrier to entry is higher. |
|
|
|
|
First, delete all posts of yours that you don't want to exist after deletion. Second, change your display name to be the name you want your surviving posts (if any) to be listed under. Finally, PM me, acknowledging that you have completed these steps.
|
|
|
|
|
I've noticed that, as well. I think we need a NNTP server.
|
|
|
|
|
This won't be popular in the long-term, since running a full node will be expensive.
|
|
|
|
|
With the 4x rule, wouldn't it take quite a few retargets before the target was properly adjusted?
|
|
|
|
|
Show Posts
