7 of 9 isn't non-standard. 

Compressed Keys
ScriptSig = 239 bytes (7*34 + 1)

Uncompressed Keys
ScriptSig = 463 bytes (7*66 + 1)

You aren't doing anything wrong.  bc.i seems to get more stuff wrong than right lately. They are just a website, they have no special significance on the network.

Then the function is no more secure than SHA-2 so why not just use SHA-2 if the goal is security?  

It still may be useful to for a PoW by moving the nonce outside of the blockheader.

R30(nonce + H(blockheader)) < target

The security of the PoW still relies on the preimage resistance of H however if R30 is irreducible then it would prevent more efficient work in the PoW.  This has the advantage of making mining hardware highly commoditized which means lower margins (anyone can do it and they work about the same) which is optimal from a security point of view.


These are weaknesses known to M-D and they are what cryptographers target when attempting to "break" the hashing function.  To date nobody has shown a preimage attack on SHA-1 or the more complex SHA-2 is possible.  

The issue of length extension doesn't apply to PoW as the header has a fixed length and ordering.  Even if you could perform a preimage attack on an existing block via length extension the resulting block would be invalid regardless of the block hash because Bitcoin blocks must be exactly 840 bytes and the elements ordered in a specific order.  

In applications where the hash will protect variable length data using a HMAC over the pure hashing function is preferable.  HMAC don't suffer from length extension attacks and they make collision attacks less effective.  Still this is academical at this point as most hashing functions are still secure against preimage attacks (even the ancient MD5).  A major goal of the SHA-3 competition was to bypass some of the weaknesses of M-D construction and as such there are theoretical length extension attacks on SHA-3. Still time trumps all, SHA-2 has been vetted more than SHA-3 at least as of today.  Maybe in a decade or so but SHA-3 is a little ahead of its time as SHA-2 held up better than NIST expected it to.

TimS,

I took a closer look at the transaction and I can't find any reason why it is being rejected by Eligius.  Unfortunately bitcoind lacks good tools for validating transactions.   Optimally decoderawtransaction & decodescript would return IsStandard and IsValid parameters but they don't.  You may want to reach out to Eligius pool directly.

SD cards can fail without warning but it is rare.  Personally I prefer paper but storing on multiple SD Cards should be secure enough.  Multiple copies exponentially reduces the chance of all copies being lost due to medium failure.  For peace of mind I like the backups to be in independent locations, to prevent all your backups being destroyed in one event (house fire destroys all three copies).  One copy in fireproof* safe at home, the other copy in safety deposit box.  A lot depends on how much you are securely storing. The precautions I would take for 100 BTC are a lot more than what I would take for 1 BTC.

* Keep in mind most "fireproof" safes are only designed to keep the interior of the safe below 350F when exposed to outside temperatures of 1500F for the rated period of time (usually 1 or 2 hours).  This is sufficient to keep paper from combusting in a normal house or light business structure fire.  Most electronic devices (including SD cards) will be destroyed if exposed to 350F for even a brief period of time.  So this is just one reason I like paper.  They do make media safes and media chests (designed to go inside a normal fireproof safe) which will keep the internal temperature much lower (usually around 125F) but one shouldn't assume they have a safe rated for media storage.

Updated.

God I hope not.  The federal regs already exist and they are down right reasonable compared to the countless pages of nonsense that NY is proposing.   The feds never followed the states when the jumped the shark on money transmitter licensing.  In an optimal scenario the feds won't expand on the existing regs.  The chairman of FinCEN testified that existing regulations were more than sufficient.

It would be possible with a hard fork.  It probably is not going to happen though.  There are however two alternate ways to accomplish the same goal.  

1) Use an AND operator in the the script.  You can make the script require Boss Signatures AND 2 of 4 workers.  Right now however this would be non-standard but hopefully that will change soon.

2) You can recreate #1 as a flat m of n by just giving the boss (mandatory signer) multiple keys.  The advantage of this is it is "standard" but it does result in larger signatures.  It could be used until #1 was included in the IsStandard checks.

Instead of 3 of 5 (with 4 workers and one boss key) make it 5 of 9 (with four workers and five boss keys)
Worker1
Worker2
Worker3
Worker4
Boss
Boss
Boss
Boss
Boss

Even if all 4 workers conspire they can't spend the coins without the boss.   Note in this example the boss (having 5 keys) could spend them without the approval of anyone else. If you don't want that to happen just give the boss one less key and make it 5 of 8.

Then Bitcoin would fail.   There is no evidence anything like that is possible.   What if Earth collided with a blackhole tomorrow?

I discovered an error in the limits that I posted upthread. The correct limits should be:

Standard
Native MultSig = max 3-of-3 (https://github.com/bitcoin/bitcoin/blob/master/src/script.cpp#L1414 "if (n < 1 || n > 3)")
P2SH w/ all compressed keys = max of 7-of-15 (https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L521 "if(txin.scriptSig.size() > 500)")
P2SH w/ all uncompressed keys = max of 7-of-7 (https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L521 "if(txin.scriptSig.size() > 500)")

Non-standard but Valid
Native MultiSig = max of 20-of-20 (update me with line reference of limit for valid OP_CHECKMULTISIG)
P2SH w/ all compressed keys = max of 15-of-15 (https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#520-byte-limitation-on-serialized-script-size)

Invalid
Native MultiSig = more than 20-of-20 (per OP_CHECKMULTISIG opcode)
P2SH = more than 15-of-15

The opcode allows up to 20 signers (i.e. 20-of-20). So for native multisig (not commonly used over P2SH) you can create a 20 of 20 transaction.  Native multisig larger than 3 of 3 are valid but not "standard" and thus won't be relayed by most nodes.

For P2SH however, the entire script must not exceed 520 bytes.  This effectively limits you to 15 of 15 multisig (7 of 7 if using uncompressed keys).  See 520 byte limit. For the tx to be "Standard" the ScriptSig must be less than 500 bytes so that limits you to 7 signatures (i.e. 7 of 15 or 7 of 7).  A larger "m" (i.e. 8 of 15) is still valid but it isn't standard and won't be relayed by most nodes.

FRIENDLY WARNING: With P2SH it is possible (actually easy) to create an invalid (unspendable) script.  Since the address is a hash of the script and the script it unknown to the network, the network has no way to validate the script at the time of funding.   You can fund an address which ultimately is unspendable.  Always test on testnet.

That is very rarely true.   It depends on what you mean by broken.  Faster than brute force no matter how much time or energy that would take (or even if the human race could generate energy on that scale)?  Sure.   Going from no know flaws to exploitable in a real world scenario. That hasn't happened to any major cryptographic hashing function in the last 30 years.  Take SHA-1 for example.  Collision attacks were found as early as 2005 however almost a decade later there isn't a single known preimage attack.  Even MD5 which wouldn't be recommended for any new application is still resistance to first and second preimage attacks.


If you could break SHA-2 there are a lot more valuable things you could do with it.  Hell even if you didn't know what to do with it you could sell it to a three letter agency for seven figures easy.  Still a flaw in SHA-2 it is unlikely to be useful to a miner.   A miner isn't looking for a single hash but rather one of trillions of quadrillions of possible valid hashes.  Mining is block is only on complexity 2^60.  If you found a flaw in SHA-2 which would allow a preimage attack on the order of 2^80 it would be huge but would still be a thousand times slower than just mining by brute force.

Eligius has some anti spam rules so instead of trying to create a zero value output why not add a second inputs so all the outputs are above the dust threshold and txn has the standard min fee.

There is no such thing as an output address.  Outputs are scripts and blockchain.info is pretty bad at decoding all but the most basic and standardized scripts.

It is more of a clarifying statute. If it wasn't explicitly stated them it would always be up to interpretation.  Business likes to see exemptions explicitly defined in black and white.  Anything which reduces uncertainty is a good thing. 


Correct.  Banks are exempt from all provisions of the regulations. Banks are also exempt from regulations for other MSBs (i.e. money transmitters, prepaid debit cards issuers, gift cards, etc) both at the state and federal level.  It is important to point out that the BSA already imposes similar KYC/AML requirements on banks so it isn't like they aren't regulated by anyone.  Still it is much nicer to be regulated by a single federal authority with a few well defined regulations than by the ever changing sea of regulations that state regulators come up with.  

As a side note, this is one reason why all prepaid credit/debit/gift cards are now issued by banks.  Yes even Discover Card and American Express are now nationally chartered banks.  Even major businesses like amazon and starbucks don't issue their own gift cards because at the state level the regulatory red tape makes it prohibitive. Instead they have a nationally chartered (and thus exempt) bank do the issuance for them in return for a fee.   The insane amount of regulatory overhead made it cheaper for issuers to become banks then try to remain compliant with 50+ state regulators. On a long enough time line we may see exchanges do the same thing, become banks to escape the neverending red tape that is state regulators.

BTW NY isn't exempting the banks because they are nice, they are just accepting reality.  A federal banking license makes what NY thinks irrelevant as federal law already exempts them from state regulators.

CA is looking to create a "bitlicense" NY just beat them to the punch.  Also CA only "legalized" Bitcoin because they previously passed a law which made issuing and circulating virtual currencies illegal.  It would be like if CA accidentally passed a law which made hamburgers illegal and then corrected it by repealing that statute.  I doubt you would consider CA to be  pro hamburger.

If you want to look at how punitive the various states will be just look at their existing MSB licenses are and when they passed them.  NY and CA were both first movers in setting up licensing and they both top the list with massive regulatory overhead.  CA maximum bond requirement for "traditional" money transmitters is $7 million.

You have two options:
a) don't do it.
b) do it and you will lose some or all of your bitcoins.

Obviously the scammers would prefer the latter.

How? What exactly could an attacker do if they gained a signed transaction?  Any bitcoin node broadcasts signed transactions to random strangers.

I have to agree with Peter.  

Schneier's law

A cryptographic primitive becomes more valuable the more it is used (which creates a self reinforcing cycle).  Better known and deployed algorithms are more likely to be researched that esoteric ones.  The longer the algorithm is around without any published breaks the higher the confidence that the algorithm can't be broken at the current time.

Namecoin (NMC) was launched in April 2011.  It was before LTC and IIRC it was the first altcoin.