This isn't possible. Even if all three bootstrap methods were shut down (which is probably itself nearly impossible), existing clients would still be able to connect easily using their address databases.

Third-party alert systems may be a good idea. These might also have faster responses than Bitcoin network alerts.

Here, I wrote a page about alerts:
https://en.bitcoin.it/wiki/Alerts

There's no documentation for this. Though it really would be a good idea for large services to check for alerts automatically.

Old versions of Bitcoin used to shut down RPC automatically when an alert was received. This should be brought back as an opt-in feature.

You can already do that by polling the getinfo "errors" field. It will fill with alert text when an alert is issued.

I've written some contingency plans for emergency network events:
https://en.bitcoin.it/wiki/Contingency_plans

Someone mentioned this months ago in another topic, and I thought it was a good idea. If plans and code are written before issues occur, then the response will be much quicker. I've not written any code for this yet, though I described the actions that should be taken after a few possible emergency events.

To get a transaction's sent value:
- Collect all prev_out structures for each "in" that is associated with one of your addresses
- For each prev_out that you have collected, find output number n in transaction with hash. The value of this output is the input's value. This transaction will exist either in your local transaction database (if you're using block hash stops), or earlier in the same mytransactions output.

The "in"s and "out"s that are not associated with your addresses can be ignored in your case.

The Tapatalk modification is a massive amount of code that is clearly messing with the security system. I don't have time to review all of this code, so I will not apply it.

Remember that the board doesn't verify email addresses.

SHlFT
Original username: Ezio
66.87.97.168, 107.29.108.104, 107.29.74.71, 107.29.92.252, 108.103.210.228, 108.116.107.92, 173.130.182.167, 173.130.62.126, 173.149.185.128, 173.96.255.163, 173.96.66.112, 184.207.25.127, 184.219.9.39, 66.87.96.215, 66.87.97.181, 66.87.97.184, 66.87.97.222, 66.87.97.230, 66.87.97.232, 66.87.97.90, 66.87.98.133, 66.87.98.151, 66.87.98.180, 66.87.98.247, 66.87.98.72, 66.87.99.20, 71.21.81.140, 72.56.215.231, 72.56.247.91
Email: auditore.sales@gmail.com
Secret question: ooi

Pearikay
Original username: zztop
66.87.96.209, 107.42.18.207, 173.106.62.117, 173.147.200.70, 66.87.96.13, 66.87.96.23, 66.87.96.254, 66.87.96.89, 66.87.96.96, 66.87.97.138, 66.87.97.168, 66.87.97.88, 66.87.98.240, 66.87.98.92, 66.87.98.96, 66.87.99.172, 66.87.99.255
Email: Alex@teleworm.com

Hollie
Original username: Darkness
184.171.168.202, 108.116.212.19, 108.116.28.128, 173.135.103.122, 173.149.144.123, 173.96.31.42, 184.209.248.98, 184.209.33.8, 184.231.206.17, 209.184.116.69, 64.134.157.255, 66.87.66.40, 66.87.96.11, 66.87.96.183, 66.87.96.195, 66.87.96.235, 66.87.96.236, 66.87.96.247, 66.87.97.136, 66.87.97.168, 66.87.97.192, 66.87.97.195, 66.87.97.212, 66.87.97.248, 66.87.98.115, 66.87.98.116, 66.87.98.151, 66.87.98.199, 66.87.98.239, 66.87.98.246, 66.87.98.47, 66.87.98.72, 70.3.226.211, 71.21.81.140, 99.200.197.89, 99.200.30.168
Email: jameslovecock@live.com

Darkness
66.87.97.248
Email: xninja.llc@gmail.com

Stefanie Andrea
107.28.115.141, 107.28.115.39, 107.28.137.251, 107.28.157.204, 107.28.189.208, 107.28.236.187, 107.28.244.20, 107.28.4.167, 107.28.98.107, 107.33.133.10, 107.33.136.196, 107.33.137.168, 107.33.139.187, 107.33.142.242, 107.33.145.229, 107.33.151.27, 107.33.168.5, 107.33.21.220, 107.33.210.140, 107.33.227.97, 107.33.251.103, 107.33.36.31, 107.33.96.37, 107.42.106.33, 107.42.155.238, 107.42.165.200, 107.42.188.172, 107.42.57.45, 107.42.92.3, 108.103.118.133, 108.125.66.189, 173.106.109.70, 173.106.119.219, 173.106.224.91, 173.106.230.69, 173.106.238.80, 173.106.40.46, 173.106.62.182, 173.115.145.46, 173.115.170.26, 173.115.212.240, 173.115.231.4, 173.115.25.75, 173.115.40.218, 173.115.55.132, 173.115.83.235, 173.147.109.202, 173.147.109.52, 173.147.112.202, 173.147.144.157, 173.147.193.37, 173.147.48.31, 173.147.72.239, 173.147.92.189, 173.147.92.235, 173.147.99.80, 173.7.104.162, 173.7.163.60, 173.7.17.165, 173.7.186.176, 173.7.205.9, 173.7.38.118, 173.7.47.95, 173.96.25.55, 209.184.116.42, 209.184.116.69, 66.87.96.113, 66.87.96.17, 66.87.96.173, 66.87.96.183, 66.87.96.209, 66.87.97.1, 66.87.97.138, 66.87.97.192, 66.87.97.248, 66.87.97.47, 66.87.97.64, 66.87.98.227, 66.87.98.228, 66.87.98.47, 66.87.99.114, 66.87.99.78, 68.241.102.227, 68.241.186.220, 72.56.144.250
Email: InfamousKraken@gmail.com

I just don't think there would be enough topics for a security section. If I saw like 30 active security topics, I would consider it.


Two of those wouldn't belong in a security section.

I already do! 

Yeah, the /q pages are there for the benefit of automated services, so feel free to use them. Please use the caching features of that page where possible, though (HTTP ETag and the "block stop point"), and don't refresh data more than every few minutes.

Yeah, I'd guess isolation. Unless the network really did produce no other blocks in that timespan.

It also works for attackers that have less than 50%. I gave average values. It's possible for an attacker to get lucky and solve enough blocks to match the network even with less than 50%.

I don't think there's any advantage to longer confirmations if the attacker is only trying to maintain control and is not replacing historical blocks.

I wouldn't be surprised if the Church of Scientology does use Bitcoin some day. LRH hated governments, so he probably would have loved Bitcoin. One of the questions on the whole-track security check is, "Have you ever debased a nation's currency?"

Maybe someone with a better knowledge of probability will prove me wrong, but this is my understanding:

To replace 6 blocks, you need to make the same number of blocks that the network makes over a period of time and then re-do the blocks you want to replace. So currently with Bitcoin it'd be 12.5 Thash/s to match the network plus a fixed (7,500,000,000,000,000 * 6) hashes to replace the last 6 blocks.

If Bitcoin had a larger block interval, you'd have the same 12.5 Thash/s to match the network, but replacing the last blocks would take many more hashes. So confirmations would represent more work and be somewhat more valuable.

Here's where he mentioned it:
http://www.youtube.com/watch?v=8OOXKrxStn0&t=20m50s

Right. Because there's a salt, so rainbow table attacks are prevented.

You said:

So you're saying that salts are helpful against attacks that do not use rainbow-table-like attacks. That is, you're saying that an attacker trying to reverse a single hash without looking at other hashes (a brute-force attack as opposed to a rainbow table attack) is worse off when there is a known salt present. This is false. In almost all password systems, salts are less than 32 characters, which does not make brute-forcing of a single hash any slower. If you're trying to slow down brute-forcing, you typically increase the number of hash iterations, which doesn't require you to store more data.

I just received a handful of these. They're pretty cool. I'm going to give one to each of my nieces and nephews.

No, it doesn't. The attacker always has the salt, so he doesn't need to bruteforce that, and hashing differently-sized data has no difference in speed when both sizes take up the same number of hash blocks. All password+salt strings under 512 bits take the same amount of time to compute with SHA-1.

Gat3way described how you can create rainbow tables for password sets when you don't use unique salts for each password.