If you need to make use of some sort of custom node (server backend for example) I would recommend running a copy of bitcoind in wallet only mode. Then have your custom node connect only to the bitcoind under your direct control.   With bitcoind acting like a bitcoin firewall it will prevent entire categories of consensus split isolation attacks.  Just keep in mind it isn't a magic bullet.   If your consensus rules are bad enough your custom node may drop blocks passed by the bitcoind and thus "stall out" but that is preferable to being fed a false history by a malicious node.

In a collision the attacker supplies both inputs and attempts to find a pair that produce the same hash output.  "Find x and x' such that x' ≠ x and H(x) = H(x)."  I can't think of many areas where true collisions present a credible attack in Bitcoin because most attacks involve "impersonating" an existing txn, block, or address.

That is exactly like an orphan block.

Some of the miners will be working on one block, some on another.   A miner from one group or the other will solve the next block and when they do the network will reorg to a consensus again.   It would do absolutely nothing other than the bad timestamps block may (or may not) become orphaned.   The most direct loser would be the creator of the block as there is a good chance he will lose the mining reward.


There are attacks that can be node with timestamps but they require the victim to be (mostly) isolated from the majority of the network.   Being poorly connected and getting isolated is always an attack vector though.

Grover's algorithm can be used to find preimages of hashing functions but the usefulness is limited though.  Finding a preimage for a hash function of length n takes O(2^n) time using a classical computer and O(2^n/2) time using a quantum computer (of sufficient size). Unlike asymmetric encryption (Shor's algorithm), the potential of quantum computing to break hashing functions (and symmetric encryption) is rather lackluster.

As for n/2 vs n/3 I have never heard of such a distinction before so I can't comment other than to say in big O terms that is pretty much meaningless.  

Is there any added benefit to using SHA256d over SHA256 in Bitcoin?

For the computing of transaction hashes, block hashes, and merkle trees Bitcoin uses SHA256d

Effectively all hashing operations are taking twice as long.   This isn't as bad as it sounds because ECDSA verification takes up the majority of the CPU cycles when verifying a block but is there any benefit to the work done in double hashing?  Or should we just accept that this was a poor implementation decision by Satoshi?  Simple if always better in cryptography so Satoshi must have had a reason to go with a double hash but I am wondering if that reason was based on flawed understanding of the limited benefits of double hashing.

Over the years I have heard a couple theories but I don't think they hold up to any scrutiny.

1) Double hashing prevents length extension attacks
This is true but length extension attacks are not useful against Bitcoin.  Length extension attacks involve signature spoofing in authentication when the send and receiver are using a shared secret.   There are no share secret communications in the Bitcoin protocol and thus there are no possible length extension attacks.

2) Double hashing provides a fallback if preimage resistance is weakened
This is also true but only for first preimage resistance which involves the input being unknown.  As such there is some merit to this rationale in using HASH160 (or any double hash) to produce the PubKeyHash (or ScriptHash) from the PubKey (or Script).   Any benefit to double hashing is lost if the address is reused as the input becomes known.   It would also only apply if due to cryptanalysis second preimage resistance was degraded but first preimage resistance was not.

This doesn't apply to any use of SHA256d because they are used in instances where the input is known.  For those unclear on first and second preimage resistance:
  

The key difference to the two scenarios is what is known to the attacker.  In the first the attacker only has the hash. A good example would be cracking a password.  In the second the attacker has the original input. A good example would be producing a "counterfeit" txn/block/merkletree/pubkey which results in the same hash as an existing one to spoof the network and steal funds.

In Bitcoin every use of SHA256 relies on second not first preimage resistance to provide security.  The input is already known so the interim hash can be computed.  The second hashing step provides no security because if the attacker finds a second input which produces the same interim hash as the target then they both will obviously produce the same final hash.  It is possible that double hashing may harden a hash against first preimage attack but that doesn't enhance the security of Bitcoin.

3) Double hashing may break a backdoor in SHA256
I believe a backdoor in a public open algorithm like SHA256 to be very unlikely.  It would have to be hidden in plain sight.   Still even if one did exist the use of a double hash could only provide protection in a first preimage scenario.   Similar to the reasons above, in a second preimage scenario the input is known and thus the adversary can separate out the two steps.

I find that unlikely.

No.  They are a randomly ordered output.   There was a bug in earlier version of the client which made determining which address was the change possible but that is no longer the case.

Block size does need to increase.  One reason it needs to increase is because hard forks require consensus (or a super majority), testing, and a phased in deployment.  It is a 6 month process easy. 

That being said overall blocks are roughly 1/3rd full.  Sure a few blocks by a few miners are large (some even just short of 1MB) but overall the network is running at roughly 1/3rd of the limit.   Even if half the hashrate dropped out, block time would be 20 minutes, adjustment would be in 2-4 weeks, and in the interim blocks would be ~2/3rds full.  For the record we aren't going to see a 50% hashrate decline in a single adjustment period but even that would be survivable.

The max block size is 1MB.   It doesn't take any longer to solve a block with 10,000 txns as it does to solve one with 1 txn.  Well it take a few miliseconds longer if that but the point is the bulk of the work is in finding the "magic nonce" and that has no bearing on the number of txns.   The average time between blocks is 10 minutes but on individual blocks there is an element of luck.  If could me 1 minute or 60 minutes.

Also the block size wasn't "over 1700 KB" that would be impossible as the block size limit is 1MB

10 minutes ago you had 1.7402113 BTC
Right now you have 1.7402113 BTC
10 minutes in the future u will still have 1.7402113 BTC

The only thing that changed is a third party's estimate of what that 1.7402113 BTC is worth.

Of course they are.  The information is public record so it should be easy to disprove
http://www.fincen.gov/financial_institutions/msb/msbstateselector.html

Looks interesting.  I will take a look this weekend. I like term "Blockchain Programming" BTW.

You can't lose funds.   They might remain stuck for a bit.  I would also stop making new txns it will just make the problem worse.

If I read this right the txn that had no fee and is unconfirmed (parent) was Blockchain.info -> brainwallet?

Ultimately either
a) a miner will include the no fee parent in a block and then all the paying child txns will be confirmed shortly
OR
b) blockchain.info will eventually delete the unconfirmed txn (the parent) and you can make a new one.   One bad thing is if this happens all the child txns will become invalid so if you used them to deposit funds at say a casino and won they likely will not give you credit.

Either way you just have to wait.

In the future don't create no fee txns unless you are willing to wait a long time (potentially days or weeks) for it to confirm and if you do then don't create any new txns from the change until it confirms.

Well every transaction afterwards can't be confirmed until the parent is confirmed.  In theory miners could use child pays parent and include both the child and parent txn in the same block but I don't know if any are searching for txns that way.   There is (currently) no mechanism to support txn replacement.    Most wallets do not allow spending unconfirmed outputs for this reason.   What wallet were you using? 

No that still is not correct.   Bitcoin QT rounds up to the next full kb so the min is always 1 KB.   Can you provide the tx id?   If you really did create the txn using bitcoin QT AND you have a fee amount set AND it was created with no fee then that would be a bug.

That would be a second preimage attack not a collision attack.  The distinction is important as the collision resistance of hashes is significantly lower than the preimage resistance.  Also at least historically preimage resistance has held up significantly better than collision resistance.

That has never happened outside of science fiction. 

It depends on what you mean by "broken".   People outside of the cryptography field often treat it is a binary outcome.  A hashing algorithm is either secure or broken when in reality it is a little more complex.

Let take SHA-1 for an example.  Unless a flaw is found there is no faster solution to a collision than a number of operations equal to 2^(hash length/2).  So for SHA-1 (160 bit length = 2^80 operations).  A flaw has been found in SHA-1 which in theory allows a collision to be found in "only" 2^61 operations.  Now that is 524,288x faster than expected (2^19) but 2^61 is still a huge number.   To date no SHA-1 collision has been found however due to Moore's law it is only a matter of time.  The important part is that this weakness was published in 2011.   Here we are in 2015 and there has not only been any real world attack (and yes lots of SSL certs still use SHA-1) there hasn't even been an academic demonstration of a collision such as showing SHA-1("useless blob of data") = SHA-1("a different useless blob of data).   Over the last 30 years breaks in hashing algorithms have occurred incrementally and slowly.  There is no reason to expect this to change in the future.

The second thing to consider is that a collision is not a preimage and for Bitcoin a collision attack would be almost useless to steal Bitcoins or reverse transactions.  A collision occurs when two arbitrary inputs produce he same hash.   For example if you created an address collision in Bitcoin the overwhelming likelihood is that it would be between two unused addresses.   Any effective attack involving bitcoin would need to be a preimage attack.  With SHA-256 that means and expected 2^256 operations. With SHA-1 there is no preimage weakness so it is still the full 2^160 despite being "weak".  Even MD5 which has a preimage weakness still requires 2^123 operations (vs 2^128 expected).

Simple version:
Given enough time it is likely that SHA-2 will eventually be considered "weakened".  That only means that the actual number of operations to find a preimage or collision will be less than the theoretical brute force attack (2^256 and 2^128 respectively).   Just because it is theoretically less secure than expected doesn't mean it is exploitable in the real world.   History has shown it has taken years if not decades to go from academic weakness to an attack with a complexity low enough that it is feasible.   This provides time to extend the protocol to support a stronger algorithm (possibly one which is provably secure or one which doesn't even exist yet).

Why can't a bank guard also cure cancer at the same time?   Not to be snarky but POW has certain important properties:
1) it needs to be cryptographically related to the current and prior blocks (which is why we hash the blockheader)
2) it needs to be a probabilistic process (any hash can solve a block but on average it will take a huge number to do so)
3) the difficulty of the solution needs to be adjustable
4) the solution on average needs to take a large amount of work to solve but take a very small amount of work to verify
5) a potential solution should be reached by any person with only access to the blockchain and memory pool (no central authority)

This is a very difficult set of requirements which is why POW is the "magic" that made Bitcoin possible.   ecurrency is various forms existed prior to Bitcoin but they required a central authority as the idea of there was no solution on how to achieve a distributed consensus among untrusted peers.

Still the heat can be used for additional work.   I think as ASICs become more commodity based (i.e. when I can buy a reel of them for immediate shipping at digikey) and energy costs dominate we will see integration of ASICs into systems that heat a house or hot water tank with the waste heat.