Offhand, maybe it shoulda been. 

I actually got started on a project the other day and it's just disturbing how feckin' easy it is to do the re-branding, re-naming, filing-the-serial-numbers-off bit.

I expanded this into three posts in my "cryptocurrency 101" series of articles on my blog, with some additions like generating keys, how to import a key to enable you to spend the genesis block coinbase transaction, etc. Also provided MIDAs - better code for difficulty retargeting, considering as this would be an altcoin that doesn't have the stability of most of the planet's hashing power supporting it.

http://dillingers.com/blog/2015/04/18/how-to-make-an-altcoin/
http://dillingers.com/blog/2015/04/21/altcoin-difficulty-adjustment-with-midas/
http://dillingers.com/blog/2015/04/23/adding-a-premine-to-an-altcoin/

Of course, there's nothing interesting yet here that would make it WORTHWHILE to have developed an altcoin.... 

You just never get tired of being wrong, do you?

I'm not even guessing about who's messing with my computers or why. Or even, really, whether;  As I said, it could all be coincidences.  It's just a funny darn string of coincidences to happen all in the same couple of days, is all. 

Looks like I went offline again last night, too. Several hours this time.  Could be the video card again. 

The deal is, this is an archive of historic source documents.  This is something that got declassified fair and square, and I'm doing something that is dead solid legal for any citizen to do.  If push comes to shove there's no crime to accuse me of over this. 

And if someone is messing with my computers, then once the archive is out well beyond their ability to find and control all the copies, there should be nothing more for them to gain by continuing to do so, and I can look forward to going back to the "usual" game of managing my machines connected to the wild wild Internet. 

As for the NSA, yeah, I'll admit to not being one of their favorite monkeys.  There's a history that goes back further than just this archive.  But I'll give them respect, because we have something in common.  Most of them - like me - are doing the best they know how to do as patriots working to keep America safe.  It's just that we have maybe some different notions of what it needs to be kept safe from. 

As regards the history questions, well, it's interesting!  Several people knew there was going to be an attack because of intercepts/decryptions.  Several people strongly suspected Pearl Harbor because of tactical considerations.   But most planners didn't believe that the Japanese had the range to hit Pearl, and were considering other targets more likely.  The crucial information that meant hitting Pearl Harbor was a possibility was that Japan had managed to move a carrier group almost close enough, and that information (also from intercepts) didn't get around fast enough to put the pieces in place before the attack.  As it was, the Japanese were operating on the extreme edge of their range; strap-on fuel tanks, difficult overloaded carrier takeoffs, planned landing on fumes or less, gear removed to save weight, etc. They had ZERO safety margin or maneuvering allowance for fuel.

I've been reading it in my spare time, and I haven't found anything that would reflect badly on them. 

Friedman was an interesting man.  Possibly something of an obsessive-compulsive, nervous, and impatient with dullards, judging by a few of the reactions others had to him, but I think that's "normal" for certain kinds of genius. 

I knew there was a controversy during and after WWII, but the perspective shift from these documents makes it look like a full scale witch-hunt - the era's equivalent to the "911 truthers" as they call themselves was convinced that the Pearl Harbor attack was either orchestrated by or known in advance by the US intelligence community, and there was a big investigation about what intercepts we had from Japan and when and whether they were decrypted. 

So far, I've not seen a shred of anything that points to anybody in the US knowing specifically about the Pearl Harbor attack before it happened.  We knew a bunch of *other* things before Pearl Harbor; The "Zimmerman Telegram" offered Mexico much of the southwestern US in exchange for coming into the war on the Axis side for example.  The crucial consideration apparently was that Mexico could take the Panama canal and allow Axis naval forces to use it, or possibly even deny its use to the US navy.  It was however, an offer which Mexico wisely declined.  We'd apparently cracked Japanese diplomatic communications enough to know that their guy in Washington was supposed to deliver a formal declaration of war a day or so before he actually did, which would have had him doing it a few hours before the Pearl Harbor attack.  In fact it seems likely that by the time the Japanese Ambassador got to the White house with the declaration, the President knew the attack had already happened but the Ambassador hadn't gotten the word yet.  Both of them had known an attack was *going* to happen, but the question of where and when apparently remained unanswered to both until the attack actually came.

It is kind of interesting that if not for the American investigation into a possible Pearl Harbor coverup, a lot of information about the UK's Bletchley Park operation that did to ENIGMA essentially the same thing the Americans did to PURPLE probably would have been buried and forgotten.  And it's also kind of interesting that while the main work of figuring out how to crack ENIGMA was done at Bletchley Park, the US evidently threw more resources into building large-scale facilities for actually decoding the intercepts and transatlantic communications about the intercepts were possible in realtime. 

None of that is new information, though. Although the level of detail from the memoranda, schedules, etc, is kind of overwhelming, that's pretty much consistent with the history as we've learnt it today. 

When someone approaches me with this proposition I need talk.  First to make sure she won't be freaked out by the notion that I'll be letting my wife know about it in advance, and that using barrier protection methods won't be a deal-breaker for her, and so on. Second because I need to have at least a 5-minute conversation with her to see if she shows any evidence of serious crazy first.

Mild crazy (lonely, depressed) I can live with, and possibly even help - hell, I'm that crazy sometimes myself.  Moderate crazy (traumatized, dependent personality) I won't get involved with unless both my wife and I have major time and energy to commit, and an environment within which such things will not get further aggravated. Serious crazy (unable to engage emotionally, schizoid, dissociative) is right out; consent issues preclude us being comfortable with these relationships, and I would refer her to  a mental health professional.

Update:

It has been an interesting couple of days since I put this up.  I've been offline three times.  Twice it was for less than a minute, because when my desktop machine crashed I failed over to a laptop that I had ready, and by the time the laptop crashed the desktop machine was ready to go again. 

Rather than trying to work out exactly *why* the desktop box crashed in the first place, I swapped out the local router, re-flashed the BIOS, and swapped out the hard drive (yes, I had another one already imaged, did that before I started; call me paranoid, I guess).  Now I'm trying to recover a memory image from the old hard drive's controller, on the off chance that there may be something interesting there. 

When the desktop box went down for the second time I didn't have the laptop ready again yet; I failed over to an older desktop machine that's been in active use as a doorstop for the last year and a half since I got my new desktop box.  And I'd been unable to find anything wrong with the router I'd swapped out, so the original router went back up with it. 

I've got the original desktop box up again, but there's something wonky about the video card now.  The fan's not working, and it siezes up if it gets too hot.  So I went and logged onto a library computer and brought home a re-flash of the video card controller on a USB stick, along with instructions on how to install it.  Aaaand, I don't know what up with my laptop machine yet; somehow it doesn't recognize its ethernet port anymore, and the first BIOS reflash didn't seem to help.

It's probably all just coincidences.   

Meanwhile, I now have over 30 peers spread across a dozen countries who have the whole archive.  So I'm counting it as a success. 

OP_CHECKLOCKTIMEVERIFY makes it possible to make txouts that cannot be spent until after some block height.

One thing that's particularly beneficial about that is that it makes it much safer for a future BIP to create nLastTime - (by analogy with nLockTime) transactions that cannot be entered into a block AFTER a given block height.  This would be the "fill-or-kill" trade that a lot of people have asked for. 

If a tx that is not valid until after block X produces only outputs that are not spendable until block x+50, then any subsequent transactions invalidated by the tx becoming invalid in a reorg are transactions that would not be valid until 50 blocks later anyway - which removes the primary problem with nLastTime.

So If nLastTime transactions are required to produce no outputs spendable within 50 blocks after their last valid block, it's "safe" insofar as not invalidating subsequent transactions, barring a 50-block reorg.

That's because you're only looking at the NSA, and the people who don't see anything wrong are looking at what the code actually does.

Yes, the NSA is a bad actor in several senses.  But you're talking about something which works in a known way that we can see and analyze.  What you're doing is sort of like claiming that there must be a hole in a steel pot because the guy who made the pot is an unethical businessman.  Well, unethical he might be.  He may have made some pots with holes in them.  But it does not mean that every pot he ever made has a hole in it.

People can still look at the pot - inspect it carefully even, test it as a pressure vessel - and find that it does not leak.  Similarly, scores of professional cryptographers and math Ph.D's have analyzed every aspect of SHA2 looking for ways to attack it, and found no leaks. 

If we could not see how it worked, or we didn't know how to search for problems, etc, then you'd have a point, but you'd also be meeting with no disagreement.  People would immediately and rightfully reject anything whose workings and structure they could not verify and analyze, notwithstanding whether they trust or do not trust its source.

Recently the NSA declassified a large cache of papers having to do with the career of William F. Friedman. 

Friedman, for those who don't know, was chief cryptographer at the NSA for many years.  Before that, he was head of research for the Armed Forces Security Agency (which became the NSA).  Before that, he was head of the US Army Signals Intelligence Service.  And before that, he trained US cryptographers for WWI.

His career spans WWI, WWII, and the early cold war era.  His papers, talks, and patents pretty much are the foundation of modern cryptography; he's the guy who published attacks on pretty much every pen-and-paper cipher system then extant, worked out the theory behind breaking rotor machines, reverse-engineered Japan's PURPLE cipher in WWII working only from intercepts, and yada yada yada....

He got interested in cryptography (published 23 monographs on the subject before WWI) in the first place because his wife, Elizabeth, was a cryptographer.  Her career is also very illustrious; mostly she did crypto for the FBI and US Coast guard, working SIGINT against gangsters and smugglers.

Anyway.  The NSA recently declassified some 52000 pages of documents (PDF files) having to do with his career.  This is pretty much everything he ever published, all his patents, and a lot of ancillary materials like schedules, memoranda, letters, personnel matters, etc.  This is as a result of an FOIA inquiry, I think. 

However, the stuff is next-best-thing-to-hidden on their site.  The files all have unhelpful numeric names and the site forbids search engines from indexing, and absolutely nothing available to civilians links into it.  Furthermore, parts of this material have been declassified before - and then "re-classified", after a tortuous legal argument that if they were able by hook or crook to get the material out of public hands they were allowed to make it secret again.  So the stuff was literally stolen from, among other places, the New York Times research files and backup microfiches and withdrawn from public view.

Anyway, my opinion is that this is all fascinating material that provides a unique and valuable perspective on America's involvement in both World Wars and the early evolution of the cold war - in addition to containing what are pretty much the foundation documents of modern cryptography.

When I discovered that this material existed, I took the liberty of downloading it all, packing it into a zip archive, and making a torrent. 

Here's a magnet link.

magnet:?xt=urn:btih:3QQIFEKHSJGNMMIFG5HJ4M2I2KLFD7WE&dn=FriedmanPapers.zip&tr=udp%3a%2f%2fexodus.desync.com%3a6969&tr=udp%3a%2f%2fopen.demonii.com%3a1337&tr=udp%3a%2f%2ftracker.leechers-paradise.org%3a6969&tr=udp%3a%2f%2ftracker.coppersurfer.tk%3a6969

Here are some trackers.

udp://tracker.coppersurfer.tk:6969
udp://tracker.leechers-paradise.org:6969
udp://open.demonii.com:1337
udp://exodus.desync.com:6969

Please get it before my machine goes down. 

Roll your own can work, but doesn't usually.  

I'm not a "great" cryptographer, I'm only a "good" cryptographer.  That means I could create something secure, but it would be an order of magnitude more expensive to compute than a secure thing designed by a "great" cryptographer.  

There's a pretty big deal about the effectiveness of various tradeoffs.  Most crypto design is all about trying to find the *minimum* amount of processing needed to achieve a particular level of security.  If you're looking for a 128-bit block size, for example, you are looking for the smallest amount of processing you can do to make sure that an opponent trying to break it has no shortcuts that can save them from having a job at least as big as trying 2^128 possibilities until one of them works.  

There's also a pretty big deal about short, simple source code where bugs and backdoors have no place to hide.  If you can't express your encryption (or your hash) in about ~120 lines of code, plus data, people have good reason to suspect that it is longer mostly to give untrustworthy actors a place to hide things in it.  If any part of your data is not constrained for known reasons to have particular values, then the community will want to see "nothing up my sleeve numbers" such as digits of pi or e or phi or a story about how the 5 FAB CAFE BABE5 AD 1 COFFEE & 3 DEAD BEEF EA.

OTOH, if you just care about "secure" and damn the amount of hardware gates or the execution time or whatever, then you'll take your 30 lines of source code or whatever, verify that it's got some provably nonlinear components such as a composition of add-with-carry and XOR, identify a "well studied" PRNG such as SPRITZ to generate a thousand rounds worth of pseudo-random S-boxes, use a Feistel construction or something to make sure it can be inverted with a key, and iterate for a thousand rounds.  

Maybe you could have achieved your security goal with 24 rounds.  Maybe if you'd designed it much more carefully and with deep understanding of all known applicable attacks you could have shown that you could have achieved it with less than 50 and so designed it with only 100 or whatever.  Most likely there's some other construction that could achieve it with ~16 rounds of much more carefully selected and designed computation, where it could be shown to take less than 20 and so someone would have designed it with only 40 rounds.  What you come up with by throwing way more resources at it than needed is likely to be a waste of time and effort and silicon that would never get accepted as a standard.  And, bluntly, if you don't know combinations of operations result in provable nonlinearity (ie, if you're not even a "good" cryptographer, let alone a "great" one) you're likely to wind up with something that's STILL insecure.  

And nobody will ever trust it, because why on earth would somebody be spending that much compute effort on something that could be done faster and more efficiently, if they had nothing to hide?  This was the problem that the community had with NIST/RSA/NSA's Dual-ECC DRBG standard; it was horribly inefficient compared to known, well-studied PRNG's like SPRITZ, so why would anybody ever use it let alone make it standard?  And then they studied it hard and searched the literature and discovered a few old papers that had postulated the possibility of a broken PRNG based on a similar construction, and then verified that the Dual-ECC DRBG was susceptible to exactly the same breakage, and suddenly understood exactly why that horribly inefficient thing was put forward as a standard.  And RSA still has egg on its face from having to recommend to its users to NOT use its own product as the whole thing became public.

Don't you get it?  This is an historic thread because if Laszlo hadn't broken the deadlock and actually started SPENDING Bitcoin in transactions for something with intrinsic value, then Bitcoin would have remained some kind of 'imaginary nerd money' that never actually made contact with the real market of goods and services and, you know, acquired any market value in the first place.  

If Laszlo hadn't spent 20K BTC on pizza, and nobody else had broken the deadlock by doing something like it, then BTC right now would not have any value whatsoever.  

I have an interesting proposal.

When subjected to ultrasonic vibrations, subsurface stress patterns in metals can relax causing changes in the metal's surface shape.  The most frequent application of this is in forensics labs recovering serial numbers from items whose cast or stamped serial numbers have been filed off but which have not subsequently been annealed or otherwise stress-released. 

You could cast your coins with the secret key, then file it off lightly and send out the coins.  If someone wants to actually spend the money, they drop it into a liquid bath with a piezoelectric crystal attached to an oscillator and leave it there for a day, then pull it out and they'll be able to read the secret key.  But at this point the coin is "defaced" because the secret key shows.  If they file it off again, stress cracks around the site will be visible.  If they don't, then the buyer will be able to know that the secret key is revealed and therefore the coin is (overwhelming likelihood) de-funded. 

I think this is more elegant than the hologram-stickers.

I think it more likely that their interest is in exploiting bitcoin than in breaking it.  What they want to do is track all the money.  Bitcoin has never been particularly private or anonymous; I'm sure that with the Internet-monitoring and data-mining capabilities they possess, they can pretty much attribute every bitcoin transaction to a particular user.  This doesn't require breaking bitcoin, or subverting its encryption or hashing, or being able to steal the money; in fact doing any of that would work against their interests since Bitcoin is likely to be the best thing that's ever happened to them in terms of making movements of money more trackable by their own resources (and not requiring pesky subpeonas or legal permissions to track) than it is by someone else's. That makes it in their best interests for Bitcoin to become the standard.



Not in evidence.  MANY people who are not on their payroll, and have serious mathematical chops, have been all over SHA looking for ways to break it.  No break has been found.  Your certainty that there must be one is not evidence of its existence.  


Embrace the power of 'and'.  They're both.  They aggressively hire mathematics and cryptography people, and not just as contractors.  They bring them onto payroll, tend to keep them employed at the same place for their entire career, and keep them up-to-the-minute with training and original work.  So yes to them being cryptographers.  They get as much as they can with cryptography, but they also have to go with what you're calling 'con' too.  With civilian crypto getting better, they are increasingly relying on protocol hacks and hardware hacks to go around the cryptography where they can't break it.  

I can picture it.  If you're an American, or even in the USA, and you manage to convince the IRS that you're Satoshi, they probably want to have a conversation about that million-or-so-coins you mined and their current value, even if you haven't cashed out a single one.

It isn't about a particular number of leading zero's, it's about getting under a particular target value.  

Satoshi's code from 2008 had an 'nBits' variable which gave a leading number of zeros that the hash had to be under; that would allow only doubling or halving.  But by the time it deployed, he had changed it to the current scheme to allow finer-grained adjustments.  I think the revision was Hal Finney's idea.  

The target value these days is encoded in 32 bits: a 24-bit integer raised to an 8-bit power of 2, which is then converted to a 256-bit integer - the set of values is the same as a 24-bit integer unsigned integer times 2 raised to some power up to 212.  

Short version of the story, the difficulty target goes up or down with a granularity of 1 part in ~8 million, so it's pretty sensitive in terms of adjustability.

Most places are recovering from the economic turbulence of recent years by inflating their currencies.  Bitcoin (or $USD) are therefore attractive in those countries as an inflation hedge.  $USD are lower risk, Bitcoin have a higher upside and also hedge against some particular disaster scenarios better - but have a much higher risk. But that's not transaction volume, that's investors.  And speculators looking for a massive price increase later too, but not people looking to use it for transactions. 

The US and its relatively anti-inflationary policies make the inflation-hedge argument less attractive for American investors, and as already noted using Bitcoin (and finding places where you can use it) is an inconvenient hassle if what you want to do is day-to-day transactions.  So Americans are not hedging inflation, they're investing mostly on the basis of speculation about a raised value in case of widespread adoption.

It is the third-world (undeveloped) and fourth-world (kleptocratic) countries I'm looking to as places where Bitcoin will gain traction for daily use.   These are places where the local currency cannot be stabilized, the laws make any use of it beyond spending it hand-to-hand just as much of a hassle as bitcoin, and there is no protection (in fact sometimes active risk) provided by local financial institutions.  In short, Bitcoin can flourish where the competition from the localized fiat economy is particularly weak. 

It is not their choice to make a block orphan, but it is their choice to mine on the parent block rather than on a block that contains one or more transactions they object to. 

If you have 50%+ of the mining power refusing transactions from some set *AND* refusing to use blocks that have transactions from that set as blocks to mine the next link in the chain from, then the chain not containing those transactions grows faster than any chain that contains those transactions.  Hence orphan blocks/chains. 

This was caused by a bug in the software that created the transaction.  Such bugs are going to happen occasionally, but the transaction it created should not have been seen as valid when it got the output amounts blatantly wrong.

The fact that we treat any over spend as an invalid transaction  but any under spend as a mining fee makes half of the cases where the amounts are blatantly wrong succeed.

All told, I call this proof that the mining fee should be explicit rather than implicit, and then any transaction where output total doesn't equal input total would be invalid.

Std Deviation is 10 minutes, but it's asymmetric.  Obviously, the odds of the next block arriving before the current one is zero (although timestamps sometimes lie to the contrary), but the odds of a block taking 20 minutes, 30 minutes, etc, are positive. 

It's got what I think of as a "half-life."  I'm not entirely sure how long the half-life is but I think it's something around 7 minutes.  So I'd expect a distribution something like: it's ALWAYS (how long since the last one doesn't matter) got a 50% chance of arriving within the next 7 minutes, 25% chance of arriving between 7 and 14 minutes, 12.5% chance of arriving between 14 and 21 minutes, etc. 

But I'm not entirely sure how long the "half-life" period is.

I just wanted to post here giving props to DeathAndTaxes for his or her patience, detailed knowledge, and willingness to help. 

D&T, you are a huge asset to the community.

I do not normally consider MultiSig or bare Pay-To-Script transactions; to me it always boils down to an "address", either P2SH or P2PKH.  I have sort of been aware that MultiSig transactions can be done otherwise, but they always come to me simply as P2PKH addresses that require multiple keys to spend.

Spending a P2SH txOut from a previous tx requires a script that was decided when that tx was created. This script must match the script hash that is stored with the txOut.  In every case where the tx whose output was being spent is a standard tx, the script will contain public keys needed to verify signatures that are also contained in the script.  Those signatures are made with corresponding private keys that are never disclosed, but the public keys (and the signatures, and the rest of the script) wind up on the block chain (public) because they are needed to verify that spending that txOut was valid.  And that is true for EVERY P2SH txOut that is being spent in a transaction.  A spend script must be provided for each.

Spending a P2PKH txOut from a previous tx requires a public key that matches a hash that was created when that tx was created.  And that key winds up on the block chain because it's needed to verify the spend of that txOut.  And that is true for EVERY P2PKH txOut that is being spent in a transaction.  A pubkey must be provided for each.

And all of this, the scripts and pubkeys required to make a valid spend of the inputs, is an entirely separate consideration from the question of what txOuts your new transaction has.  You can make txOuts from the new transaction be MultiSig, or P2PKH, or P2SH.   Or a few of each. 

Every significant part of a tx must be signed by one or more of the people spending the coins in order for the tx to be valid.  But if there is more than one input to a tx, they can each sign just the ones that they're contributing: that is, if Bob and Alice are both spending one txOut from previous transactions to make the current transaction, it's perfectly fine to have Bob provide the script and/or signature for the txOut he's spending, and Alice provide the script and/or signature for the txOut she's spending.  Usually both or all of them will provide signatures that cover all the outputs of the new tx, but this isn't a requirement.  You might have Alice signing only the input she's providing and one of the new txOuts and Bob signing two other inputs and all of the new txOuts.

I don't think this is clearer than what D&T was saying, but maybe it boils things down a bit or presents it from a different perspective that may help.