No the blocks are invalid because they contain invalid txns.   This is not a "IsStandard() check it is an valid vs invalid check. A block containing a txn with a push larger than 520 bytes is no more valid than one containing a coinbase generation of 500,000 new Bitcoins. 

In theory yes but even proponents of reversible computing don't believe leakage will be that low.  There is the energy cost required to perfectly isolate the circuit from the outside environment so even if your raw circuit was perfectly reversible the total system energy cost will be much higher.

Also theory is just theory.  In theory it is possible for someone to make a miner with 5,000,000 G/J (instead of 1 G/J) using plain boring classical computing.  Granted you aren't going to do it with 20nm silicon but in theory it can be done.  Now 5,000,0000 PH/s well we know that is not possible without a massive reduction in the "work" needed to complete a single hash.  "In theory" is a nice way of saying nobody has proved it impossible.

Maybe in 50-80 years.  Nobody has successfully implemented a 32 bit adder using reversible computing.  If you think quantum computing is in its infancy well reversible computing hasn't even been born yet.  Despite the theory being published in 1973 to date there has been pretty much no practical demonstration of implementing the most trivial of reversible circuits.

Part of the problem is that the circuit must be very insulated from the outside environment in order to remain reversible.  To date this means a lot of very expensive near zero superconductors but even esoteric problems like a stray cosmic ray striking your circuit can leak to large scale leakage.  To say the future of mining obviously involves reversible computing is sort of like suggesting Honda should stop researching hybrids and start researching hyperdrives because obviously on a long enough timeline some form of faster than light travel is an obvious requirement for a spacefaring civilization. There is a lot of potential improvement in classical computing.  We something like a million times less efficient than the thermodynamic limit.  

Also as Peter points out there is still an energy time tradeoff.  If I gave you today a reversible miner which ran on near zero energy but had a hardware cost $10,000 of per GH would you be interested?   If the technology is more expensive on an amortized per hash total lifecycle cost than classical computing well it doesn't really matter how little energy it uses.

Now that most P2SH redeem scripts are standard you can create multisig scripts which uses addresses (pubkehash) instead of pubkeys.  Client support for signing that script is another thing.  So this is more a client implementation detail not a protocol limitation.

The problem is that simply having an IP address that is accessible or completing a low diff POW doesn't mean you are actually a node.   Proving you are actually a node especially over an extended period of time is a non-trivial problem.

When two miners solve different blocks at the same height at roughly the same time they will both broadcast the block to the network.  A node will only relay and build off the first block at a given height in a race condition.  This means until the next block was solved some of the network considered DF block and some considered AP block to be the 'best block'.  The network is temporarily 'divided'.  Miners will be working on different forks however the fork is resolved by a reorg when a miner solves the next block. In this case it was BW and since they received DF block first they extended that chain.   If a miner/pool which received AN block first and thus was extending that chain solved the next block then the network would have reorged to that fork instead.

Now all this assumes that both pools are operating nodes which follow the standard consensus rules.  It would be possible for two (or more) pools to reach a secret agreement to always build the fork containing each others blocks in a split but that would be a losing proposition unless the pools had more than 50% of the total hashrate combined.  There is no evidence that is what happened in this scenario just pointing out that it is always possible.

Everything is compared to symmetric encryption because baring a flaw in the algorithm there is no method to find a symmetric encryption key faster than O(n) steps.  All other algorithms have solutions than can be found in less steps.

ECC is "secure" because the Elliptic Curve Discrete Logarithm Problem is infeasible for large sets however there are solutions to the ECDLP which are faster than O(n) but the fastest (such as pollard's rho) is still O(n^1/2).  Since the solution can be found in faster than O(n) steps it requires a larger key for an equivalent level of security.

Keep in mind that the ratio of relationship of O(n^1/2) between key size and bit strength only applies to ECC and only because there no faster solution is currently known.   This can change over time.  The strength of a given RSA key has declined over time as faster solutions to the integer factorization problem have been found.  Today to achieve '128 bit security' requires a 3,072 bit RSA key.

No and probably will not be for sometime if ever.


A hard fork and new block header format just to move the extranonce to the header?  No it probably isn't worth it.  My post was more to illustrate that expanding the header is possible while still being backwards compatible with existing ASIC hardware.  Eventually the header will probably need to be updated for one reason or another.

The 'work' is recreating the merkle tree not the single hash of a single tx.  A change to the tx set will require recomputing the merkle tree.   It really isn't that much of a problem.  If the block header is updated it would be very smart to put a extanonce in the header itself to prevent needing to recompute the merkle tree but hashing even the full merkle tree is not that much of a load compared to the cost of ECDSA validation.  So I would chalk it up as a "it would be nice to do if we are updating the header format anyways".

The script verifies the pubkey in the current txn hashes to the pubkeyhash in the output of the PRIOR txn.

The blockchain disagrees with you.

Alice. 

When Carol sent coins to Alice it was a Pay2PubKeyHash transaction.  The address Alice gave Carol contains the PubKeyHash.  So the output of Carol's txn (called PkScript) contains only the PubKeyHash.

When Alice spends that txn she needs to include in the input (ScriptSig) the PubKey which hashes to the PubKeyHash in the prior txn.

A txn with an invalid signature will be invalid to all nodes.   All nodes validate signatures of txns and will not relay invalid txns.  A node sending invalid txns will be seen as misbehaving and will be banned.  Wallet behavior is different than node behavior.  A node should respond consistently based on what is known publicly (regardless of what private keys are in the local wallet or even if there is a local wallet).  If that isn't the case then there is an information leaking bug.  There was a 'penny flood' bug in the past but it didn't involve invalid signatures and has been patched consistently as of v0.80 (plus some earlier versions).


Exactly.  All nodes verify txns before relaying thus all nodes will ban a node sending a txn with an invalid signature.


Transactions which have outputs less than the dust threshold are valid. They are non-standard but any miner can include non-standard but valid txns in the block to be solved.  Some pools will accept non-standard txns.

Which has what to do with the claimed lack of deniability?  So some people may choose to misuse the proposal that doesn't weaken the security of those who use it as proposed (random value encoded as mnemonic plus optional passphrase with deniability).

Then there is no such thing as deniable cryptography under any circumstance.  The definition of what is deniable has been stretched to a point where no possible cryptographic system can fit it and thus there is no point in either using the term.  I would hope you can see that if you graphed all scenarios involving deniability at least some of them would fall on the spectrum short of torture.

Honestly if you suspect you will be tortured in the near future you should NOT use deniable cryptography.  Why? because it is deniable.  Say you give up the sacrifice key but they torture you.  Maybe now you aren't holding out to protect the key but the fact that it is very likely they will kill you once they get it.  Eventually you crack though and give them the second key.  Bad news for you is that one of the torturers turns to the other one and says "what if there is a third key".  Now there is no third key but you can't prove that there isn't.  Under torture you may swear there is no third key but of course you would say that.  So with no way to provide what they want and no way to prove you don't have what they want you are going to die a very slow and painful death.

No deniable system can prevent compromise due to a weak key or disclosure of key by force.   The first is a limitation of any cryptographic system and the second isn't even a cryptographic problem.   It is like saying locks on your door aren't useful because I could always torture you until you open it.

It isn't random mnemonic OR passphrase it is random mnemonic AND (optional) passphrase.   The comparison to brainwallet is inaccurate.  Would you call bitcoin core's encrypted wallet a brainwallet?  Of course not unless you stretch the definition to the point of being silly.   You need the wallet.dat PLUS the (optional) passphrase.  Here you need the mnemonic PLUS the (optional) passphrase.    Precomputation isn't possible in either scenario.

Thanks for finding it.  That was the thread.  I think this post is clearer:
https://bitcointalk.org/index.php?topic=626377.msg6975690#msg6975690

Luckily that is not correct.  A while back I proposed a way to expand the header while still maintaining compatibility with existing ASICs (but would require a hard fork and updated mining software). Maybe I can find a link.  The header will eventually need to be updated when the Unix time value overflows the 32 bit integer but we have a 'little' while before that happens.

Correction, the output contains only the pubkeyhash not the pubkey so the ScriptSig will need to provide both the Signature and the PubKey.  There is only one possible order however.


Yes.  The ScriptSig is mutable.  You or anyone can change the order of the Signatures.  The person broadcasting the txn will need to ensure they are in the correct order before broadcasting.  If in an invalid order the txn will be dropped as invalid.  Technically nodes could be designed to change the order as necessary and 'fix' the txn for you but they don't as that could be used as a DDOS vector.  Keep in mind that changing the order of the signatures (or anything in the ScriptSig) will change the TxId.

Care to explain further?  I am not sure what you mean by nearby key.  The output of PBKDF2 should approximate a random oracle.  The closest thing would be a brute force attack on weak passphrases to search for potential key trees.  I remain skeptical of an attack vector which is faster than a brute force search of passphrases and certainly not one which can be done with a gpu in a second.  So lets make sure we are talking about the same thing.


Let m be a given BIP39 mnemonic and p and p' be two distinct passphrases.  Unique seeds s and s' and produced using BIP-33.  I argue that s' can not be derived without knowing p' even if m and p are known if s' is sufficiently strong to make brute force search infeasible.

s = PBKDF2(m, "mnemonic"+p, HAMC-SHA512, 2048) where s is the derived seed, m is the mnemonic (128 bit to 256 bit random value), and p is the passphrase.

I see nothing in the details which makes it weaker than a hypothetical KDF so lets simplify it to a generic representation as:
s = KDF(m, p) where s is the derived seed, m is a random value with at least 128 bits of entropy and p is a user supplied passphrase

So given two unique passphrases and the same mnemonic we have:
s = KDF(m, p)
s' = KDF(m, p')

Are you saying that s' can be derived knowing m & p and not knowing p' just using a GPU powered laptop?  If not then there is no way to link any child derived keys (BIP32) without knowing p even if m is known.  If there is some vulnerability please show it to me.