SVN has Unix line endings, while the source in the packages has Windows line endings. The files are otherwise exactly the same.

In this case, I think the block chain would be kept for both versions. Both will perceive the other as "breaking the rules", and see themselves as the legitimate version of Bitcoin.

When comparing the max number of bitcoins to the current USD M1, 1 BTC = ~84,076 USD.

That's probably the case, but something must have failed really badly. His block count is constantly stuck at 1698, but he somehow managed to generate and mature 13,000 BTC? He's generating at a work computer, so maybe it's some crazy antivirus.

Just to be sure that the entire balance is bad (maybe it just failed recently), Dhaw should post the raw transaction so that the inputs can be checked against the block chain.

Dhaw:
1. On the computer where you sent the 8,750, modify the Bitcoin shortcut so it runs in debug mode:
http://img264.imageshack.us/img264/2526/85647303.png
http://img146.imageshack.us/img146/723/90684161.png
2. Run Bitcoin.
3. Double-click the 8,750 transaction:
http://img525.imageshack.us/img525/6200/90747626.png
4. Copy all of the "inputs" to http://pastebin.com/ and post the link here.
http://img263.imageshack.us/img263/6645/68205424.png
To copy from that window, you have to use Ctrl+C after selecting the text. I've found that it sometimes takes a few tries to work.

Bitcoin would almost certainly be forked if that happened. The fork could easily preserve all Bitcoin balances up to the change.

This situation would be great for early adopters, since you'd be able to legitimately double-spend all of your pre-fork balances.

Dhaw sent me some of his debug.log files. Symptoms I saw:
- In most of the files his block count remains "stuck" at 1698.
- In one file he accepted blocks beyond that, but it went back to 1698 after he restarted Bitcoin.
- Any blocks he receives after 1698 he probably considers invalid. I haven't seen the actual block rejection (it keeps getting removed by the auto-trim), but his debug.log is full of "block xxx have" messages for blocks that he clearly doesn't recognize as valid.
- He is connected to real peers. He connected successfully to IRC, and he was able to connect to me with -addnode. I verified at my end that he is successfully sending getblocks messages.

I'm almost sure that Dhaw is not a scammer, and is a victim of some bug. My guess is that every time he restarts Bitcoin, his block database is corrupted.

He speaks 'Portuguese (Brazilian)'. A translator would be helpful.

I use dm-crypt. You must be root to mount the encrypted device. You can use a file-based container with a loop device.

My mount script:

Unmount:

Probably all 4 billion IP addresses are on some black list or other. These lists are extremely unreliable.

Feel free to block them if you want. Bitcoin will use the backup bootstrap method, which is slower but just as effective.

The port 80 addresses are used for determining your external IP addresses (www.ipaddressworld.com, checkip.dyndns.org). Port 6667 is IRC, which Bitcoin uses for bootstrapping (irc.lfnet.org).

It's also possible for Bitcoin peers to run on different ports, though they would have to modify the source code.

If he sends the BTC first, there's no problem. You would be the one who could issue a chargeback.

When talking about physical Bitcoin cards/tokens, most people assume that either a central server or use of QR codes would be needed to redeem the bitcoins. However, it is possible to use Bitcoin's scripting system to make bitcoin transactions redeemable with a short code, without any centralized server.

The person who is creating the physical Bitcoin card creates a transaction with an output like this:

Then to redeem this transaction, the person who receives the card creates a transaction to himself with an input containing the code and signature. The code and the rest of the private key are on the card.

I imagine that a Bitcoin scratch-off would have the full transaction hash on the front and the code/key under the scratch-off portion in base58. To redeem, start typing the hash into your Bitcoin client until it tells you that it has enough to identify a single transaction (only 4-8 bytes are necessary). Then type the code/key. The money is instantly yours, with no central server necessary. If you have a computer handy while buying the card, you can verify that a card is still valid by looking at the hash on the front (the code could be fake, of course).

The first few bytes of the private key can be used as a salt.

Without the public/private keys, it would be easy for any man-in-the-middle (including any Bitcoin node) to rewrite your transaction to himself after receiving it. It's still possible for him to do this, but he would have to preemptively brute-force the full private key from the portion in the transaction, and then he would have to re-sign his new transaction on-the-fly in less than a few seconds. I think this makes the attack difficult enough for the scheme to be usable.

This can be significantly improved if the mathematical script functions are enabled (alternatively, I believe OP_SUBSTR could do the same thing):
- The output of the first transaction contains the full private key, but it requires that the provided signature start/end with some number of zeroes.
- To redeem, you need to modify and re-sign your transaction (using a nonce value with OP_DROP) many times to get a signature that meets the requirement. The number of zeroes required should be set so that this calculation takes only 5-10 minutes on most computers.
- To modify your transaction, the attacker needs to re-sign the transaction. However, he can't do it in less than the 5 seconds or so required because of the proof-of-work.

An 8-byte code would probably be sufficient. Each byte has 256 different possible combinations instead of the 96 with standard ASCII, so this would be stronger than a 16-character totally-random password. I'm unsure about the security of giving away a partial private key; if it's only possible to brute-force, 16 bytes would probably be enough, though I'd probably err on the side of caution with 32 bytes.

So if the arithmetic functions are enabled in Bitcoin, that's less than 20 characters you'd have to type: 8-10 characters for the transaction hash and 8-10 characters for the code. Anyone could generate these codes. It might be a useful cash-alternative among people who already trust each other, and it'd be very convenient for selling bitcoins at physical shops.

(Edit: realized how to use a salt without OP_CAT.)

For every leading 0x00 byte, add a leading 1 (encode). For every leading 1, add a 0x00 byte (decode). For encode, don't accept input that doesn't have an even number of bits (divisible by eight), as this doesn't make sense. For decode, pad leading zeros until you have an even number of bits.

I just check that the output immediately post-DecodeBase58 (including leading zeroes, checksum, versionNumber) is 25 bytes long. I think that Bitcoin does something similar to this.

I made some web tools for dealing with addresses:
http://theymos.ath.cx:64150/q/checkaddress
http://theymos.ath.cx:64150/q/addresstohash
http://theymos.ath.cx:64150/q/hashtoaddress
http://theymos.ath.cx:64150/q/hashpubkey
(Source not public yet.)

Most of the "download" time is actually caused by the verification of all the blocks (doing the crypto verification on 130,000+ transactions). The actual download doesn't take very much time at all, as you can see if you download the database files. Things could be sped up considerably if Bitcoin just skipped verification on blocks before the latest checkpoint. There's a philosophical difference, though, which is probably why this is not already done: the checkpoints tell you when the blocks are wrong, but skipping verification would tell you when they are right, which makes things more centralized.

The article is full of plagiarism from Bitcoin Market and bitcoin.org.

Harley4noble is a spam bot...

They will be. Everything is.

Every received IP transaction creates a new address (taken from the pool), so be careful if you are accepting those. Someone could empty your pool in a few minutes.

Yes. It's a good idea. If a transaction that conflicts with yours is spotted through the network or in a block (even a block in a shorter chain), then remove your version from all RPC listings and display it specially in the UI. The existence of any conflicting transaction means that the person who sent you the transaction is trying to defraud you.

If you double-spend, then both recipients will get transactions with 0 confirmations. The network isn't sure yet which one came first, since the simple TCP network can't be counted on. Normally after one block the network will decide which one is valid. However, it is possible (though unlikely) for two blocks containing different versions of the transaction to be generated at the same time, in which case it would take another block to figure out which one is valid. (It's possible for this to happen a second time, but too unlikely to think about.)

So a detection mechanism could say, "This new block would replace a block that is 5 blocks deep in the main chain. Any transactions in that chain that conflict with transactions in the main chain are likely to be double-spends." It could not say (with reliable accuracy), "This new block is now the latest block in the main chain. However, one of its transactions conflicts with one that I received via the TCP network first, so the block's version must be a double-spend."

You could probably distinguish original transactions from double-spent ones if the attacker is rewriting blocks that are more than one block deep. You can't be sure for transactions with only 0 or 1 confirmations, since this kind of "split opinion" could occur naturally.

If the legitimate network regains control and it's clear that the main block chain is full of double-spends, the network could start building on some shorter chain before the event to reverse the double-spends. This would probably also reverse some legitimate transactions, though.

Just detecting that someone is messing with the network is much easier, and I wouldn't be surprised if Bitcoin does try to detect this at some point.

Bad argument. 7200 BTC are created daily.