Oh my Satoshi
Bitcoin P2P Currency: The Most Dangerous Project We've Ever Seen
May 15, 2011
by Jason Calacanis
Solid discussions of this piece on BoingBoing.net, Hacker News, Slashdot and Reddit. Rob Tercek has a follow up to this piece here.
by Jason Calacanis and the LAUNCH team
A month ago I heard folks talking online about a virtual currency called bitcoin that is untraceable and un-hackable. Folks were using it to buy and sell drugs online, support content they liked and worst of all -- gasp! -- play poker.
Bitcoin is a P2P currency that could topple governments, destabilize economies and create uncontrollable global bazaars for contraband.
I sent the 30 or so producers of my show This Week in Startups out to research the top players, and we did a show on Bitcoin on May 10. Since that time the number of bitcoin stories has surged.
After month of research and discovery, we’ve learned the following:
1. Bitcoin is a technologically sound project.
2. Bitcoin is unstoppable without end-user prosecution.
3. Bitcoin is the most dangerous open-source project ever created.
4. Bitcoin may be the most dangerous technological project since the internet itself.
5. Bitcoin is a political statement by technotarians (technological libertarians).*
6. Bitcoins will change the world unless governments ban them with harsh penalties.
Bottom line: The world is going to be turned over by bitcoins unless governments step in and ban them by prosecuting individuals.
This is about to get really interesting, everyone.
Full article on original source:
"The root problem with conventional currency is all the trust that's required to make it work. The central bank must be trusted not to debase the currency, but the history of fiat currencies is full of breaches of that trust. Banks must be trusted to hold our money and transfer it electronically, but they lend it out in waves of credit bubbles with barely a fraction in reserve. We have to trust them with our privacy, trust them not to let identity thieves drain our accounts."
— Satoshi Nakamoto
27 May 2011
Bitcoin's long gestation and early opposition indicates it is an example of the 'Worse is Better' paradigm in which an ugly complex design with few attractive theoretical properties compared to purer competitors nevertheless successfully takes over a niche, survives, and becomes gradually refined.
LulzSec, Anonymous … freedom fighters or the new face of evil?
August 9, 2011
by Craig S Wright
PhD; Adjunct Lecturer in Computer Science, Charles Sturt University
As you’ll know by now, hacktivist group Anonymous has vandalised the home page of the Syrian Ministry of Defense, posting a message which started: “To the Syrian people: the world stands with you against the brutal regime of Bashar Al-Assad”.
The response from within Syria was swift, with the so-called “Syrian Electronic Army” retaliating by defacing Anonymous’s fledgling social network, Anon+.
So, was the backlash uncalled for?
Groups such as LulzSec and Anonymous have what many see as laudable goals.
They promote freedom, or at least they claim to. The real question in all this is: what constitutes freedom?
After reading Gavins thread on public relations, I wanted to find an easy way to make Bitcoin come across as a more professional, trustworthy project. I don't need to explain why that's an important image to establish.
So I changed my forum display name from [mike] to my real name, which was easily available from the BitCoinJ project anyway. Quite a few important players in the Bitcoin community aren't actually anonymous even though they use nicks on this forum. When people evaluate Bitcoins potential, one question they ask is, who are these people? Is anyone seriously standing behind this project? Just using our real names when posting is a simple step that will re-assure people who are deciding whether it's worth their time. So I encourage you to do the same - it's easy to do by going into the profile tab and clicking "Account Settings".
Here's a quick reference guide to some of the communities top contributors, based on publicly available information:
- Gavin Andresen, no need to introduce the project maintainer. He previously worked at Silicon Graphics and now runs his own company.
- MagicalTux - Mark Karpeles, owner of MtGox and Kalyhost
- Vladimir Marchenko, runs Marchenko Ltd which sells mining contracts, previously developed the figator.org search engine.
- xf2_org - Jeff Garzik, who does kernel development at Red Hat
- BlueMatt - Matt Corallo, core developer
- sipa - Pieter Wuille, core developer and maintainer of the network graphs
- justmoon - Stefan Thomas, creator of the WeUseCoins.com site/video and WebCoin.
- Hal - Hal Finney, one of the creators of PGP
- mndrix - Michael Hendrix, creator of the (sadly defunct) CoinPal and CoinCard services
- theymos - Michael Marquardt, creator of the widely used blockexplorer.com site
- genjix - Amir Taaki, creator of the Britcoin exchange
- Mike Hearn - Google engineer who works on Gmail and developed BitCoinJ
There are a few others I know based on private information. If you're OK with appearing here (or not appearing here) let me know.
BTW I know plenty of people posting in these forums prefer to be totally anonymous, and there's nothing wrong with that.
1st fork of Bitcoin
18 April 2011
Unlike bitcoin, Namecoin can store data within its own blockchain transaction database. The original proposal for Namecoin called for Namecoin to insert data into bitcoin's blockchain directly. Anticipating scaling difficulties with this approach, a shared proof-of-work (POW) system was proposed to secure new cryptocurrencies with different use cases.
Namecoin's flagship use case is the censorship-resistant top level domain .bit, which is functionally similar to .com or .net domains but is independent of ICANN, the main governing body for domain names.
February 18, 2011, 08:50:57 AM
1 satoshi = 1 microbitcent (smallest denomination)
100 million satoshis = 1 bitcoin
Are we agreed?
February 18, 2011, 10:51:26 AM
no to the gold cult
From: Mike Hearn firstname.lastname@example.org Date: Mon, Dec 27, 2010 at 8:21 PM To: Satoshi Nakamoto email@example.com
Happy Christmas Satoshi, assuming you celebrate it wherever you are in the world :-)
I have been working on a Java implementation of the simplified payment verification, with an eye to building a client that runs on Android phones. So I've been thinking a lot about storage requirements and the scalability of BitCoin, which led to some questions that the paper did not answer (maybe there could be a new version of the paper at some point, as I think aspects of it are now out of date).
Specifically, BitCoin has a variety of magic numbers and neither the code nor the paper explain where they came from. For example, the fact that inflation ceases when 21 million coins have been issued. This number must have been arrived at somehow, but I can't see how.
Another is the 10 minute block target. I understand this was chosen to allow transactions to propagate through the network. However existing large P2P networks like BGP can propagate new data worldwide in <1 minute.
The final number I'm interested in is the 500kb limit on block sizes. According to Wikipedia, Visa alone processed 62 billion transactions in 2009. Dividing through we get an average of 2000 transactions per second, so peak rate is probably around double that at 4000 transactions/sec. With a ten minute block target, at peak a block might need to contain 2.4 million transactions, which just won't fit into 500kb. Is this 500kb a temporary limitation that will be slowly removed over time from the official client or something more fundamental?
From: Satoshi Nakamoto <firstname.lastname@example.org>
Date: Wed, Dec 29, 2010 at 10:42 PM
To: Mike Hearn <email@example.com>
The simplified payment verification in the paper imagined you would receive transactions directly, as with sending to IP address which nobody uses, or a node would index all transactions by public key and you could download them like downloading mail from a mail server.
Instead, I think client-only nodes should receive full blocks so they can scan them for their own transactions. They don't need to store them or index them. For the initial download, they only need to download headers, since there couldn't be any payments before the first time the program was run (a header download command was added in 0.3.18). From then on, they download full blocks (but only store the headers).
Code for client-only mode is mostly implemented. There's a feature branch on github with it, also I'm attaching the patch to this message.
Which symbol do you like best?
฿ - 200 (42.2%)
ⓑ - 35 (7.4%)
Ⓑ - 68 (14.3%)
Ƀ - 96 (20.3%)
¤ - 1 (0.2%)
None of the above - 74 (15.6%)
Total Voters: 470
Re: Official Bitcoin Unicode Character?
The first recorded exchange rate was 1309 BTC per USD
How I Met Satoshi
Published by Jon Matonis on May 2, 2016
My relationship with the individual known as Satoshi Nakamoto started in early March 2010 when I received an email from Satoshi pointing me to the published Bitcoin white paper and encouraging me to investigate the system and to begin promoting the network by transacting and mining. At the time, I managed a digital currency blog and this was an email relationship with some brief correspondence.
Cracked, inSecure and Generally Broken
The ravings of a SANS/GIAC GSE (Compliance & Malware) Security, Digital Forensics Statistics and Data Mining. I mined Bitcoin in the past and write code.
Re: Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIG
published by Satoshi Nakamoto at Bitcointalk forum
The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime.
Because of that, I wanted to design it to support every possible transaction type I could think of. The problem was, each thing required special support code and data fields whether it was used or not, and only covered one special case at a time. It would have been an explosion of special cases. The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates. The nodes only need to understand the transaction to the extent of evaluating whether the sender's conditions are met.
The script is actually a predicate. It's just an equation that evaluates to true or false. Predicate is a long and unfamiliar word so I called it script.
The receiver of a payment does a template match on the script. Currently, receivers only accept two templates: direct payment and bitcoin address. Future versions can add templates for more transaction types and nodes running that version or higher will be able to receive them. All versions of nodes in the network can verify and process any new transactions into blocks, even though they may not know how to read them.
The design supports a tremendous variety of possible transaction types that I designed years ago. Escrow transactions, bonded contracts, third party arbitration, multi-party signature, etc. If Bitcoin catches on in a big way, these are things we'll want to explore in the future, but they all had to be designed at the beginning to make sure they would be possible later.
I don't believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network. The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint.
Re: Scalability and transaction rate
"The current system where every user is a network node is not the intended configuration for large scale. That would be like every Usenet user runs their own NNTP server. The design supports letting users just be users. The more burden it is to run a node, the fewer nodes there will be. Those few nodes will be big server farms. The rest will be client nodes that only do transactions and don't generate." —satoshi
Discussion between Daniel Larimer and Satoshi Nakamoto, July 28-29, 2010
Craig S Wright
"Instead of the supply changing to keep the value the same, the supply is predetermined and the value changes. As the number of users grows, the value per coin increases. It has the potential for a positive feedback loop; as users increase, the value goes up"
Satoshi Nakamoto, 2009
New icons, what do you think? Better than the old one?
Full size 530x529 image for scaling down to custom sizes:http://www.bitcoin.org/download/bitcoin530.png
The perspective shadow was too thick on the larger sizes. I updated 32, 48 and the full size.
I release these images into the public domain (copyright-free). I request that derivative works be made public domain.
Posted by Satoshi Nakamoto on February 11, 2009 at 22:27
I've developed a new open source P2P e-cash system called Bitcoin. It's completely decentralized, with no central server or trusted parties, because everything is based on crypto proof instead of trust. Give it a try, or take a look at the screenshots and design paper:
Download Bitcoin v0.1 at http://www.bitcoin.org
The root problem with conventional currency is all the trust that's required to make it work. The central bank must be trusted not to debase the currency, but the history of fiat currencies is full of breaches of that trust. Banks must be trusted to hold our money and transfer it electronically, but they lend it out in waves of credit bubbles with barely a fraction in reserve. We have to trust them with our privacy, trust them not to let identity thieves drain our accounts. Their massive overhead costs make micropayments impossible.
A generation ago, multi-user time-sharing computer systems had a similar problem. Before strong encryption, users had to rely on password protection to secure their files, placing trust in the system administrator to keep their information private. Privacy could always be overridden by the admin based on his judgment call weighing the principle of privacy against other concerns, or at the behest of his superiors. Then strong encryption became available to the masses, and trust was no longer required. Data could be secured in a way that was physically impossible for others to access, no matter for what reason, no matter how good the excuse, no matter what.
It's time we had the same thing for money. With e-currency based on cryptographic proof, without the need to trust a third party middleman, money can be secure and transactions effortless.
One of the fundamental building blocks for such a system is digital signatures. A digital coin contains the public key of its owner. To transfer it, the owner signs the coin together with the public key of the next owner. Anyone can check the signatures to verify the chain of ownership. It works well to secure ownership, but leaves one big problem unsolved: double-spending. Any owner could try to re-spend an already spent coin by signing it again to another owner. The usual solution is for a trusted company with a central database to check for double-spending, but that just gets back to the trust model. In its central position, the company can override the users, and the fees needed to support the company make micropayments impractical.
Bitcoin's solution is to use a peer-to-peer network to check for double-spending. In a nutshell, the network works like a distributed timestamp server, stamping the first transaction to spend a coin. It takes advantage of the nature of information being easy to spread but hard to stifle. For details on how it works, see the design paper at http://www.bitcoin.org/bitcoin.pdf
The result is a distributed system with no single point of failure. Users hold the crypto keys to their own money and transact directly with each other, with the help of the P2P network to check for double-spending.
AN ARCHIVED COPY OF A NOW-DELETED BLOG POST FROM WRIGHT DATED JANUARY 10, 2009, WHICH READS: “THE BETA OF BITCOIN IS LIVE TOMORROW. THIS IS DECENTRALIZED… WE TRY UNTIL IT WORKS.” (THE POST WAS DATED JANUARY 10, 2009, A DAY AFTER BITCOIN’S OFFICIAL LAUNCH ON JANUARY 9TH OF THAT YEAR. BUT IF WRIGHT, LIVING IN EASTERN AUSTRALIA, POSTED IT AFTER MIDNIGHT HIS TIME ON THE NIGHT OF THE 9TH, THAT WOULD HAVE STILL BEEN BEFORE BITCOIN’S LAUNCH AT 3PM EST ON THE 9TH.) THAT POST WAS LATER REPLACED WITH THE RATHER CRYPTIC TEXT “BITCOIN – AKA BLOODY NOSEY YOU BE…IT DOES ALWAYS SURPRISE ME HOW AT TIMES THE BEST PLACE TO HIDE [IS] RIGHT IN THE OPEN.” SOMETIME AFTER OCTOBER OF THIS YEAR, IT WAS DELETED ENTIRELY.
The Times 03/Jan/2009 Chancellor on brink of second bailout for banks
Jan 03 2009
A genesis block is the first block of a block chain. Modern versions of Bitcoin number it as block 0, though very early versions counted it as block 1. The genesis block is almost always hardcoded into the software of the applications that utilize its block chain. It is a special case in that it does not reference a previous block, and for Bitcoin and almost all of its derivatives, it produces an unspendable subsidy.
Main network genesis block
Here is a representation of the genesis block as it appeared in a comment in an old version of Bitcoin. The first section defines exactly all of the variables necessary to recreate the block. The second section is the block in standard printblock format, which contains shortened versions of the data in the first section.
GetHash() = 0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f hashMerkleRoot = 0x4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b txNew.vin.scriptSig = 486604799 4 0x736B6E616220726F662074756F6C69616220646E6F63657320666F206B6E697262206E6F20726F6C6C65636E61684320393030322F6E614A2F33302073656D695420656854 txNew.vout.nValue = 5000000000 txNew.vout.scriptPubKey = 0x5F1DF16B2B704C8A578D0BBAF74D385CDE12C11EE50455F3C438EF4C3FBCF649B6DE611FEAE06279A60939E028A8D65C10B73071A6F16719274855FEB0FD8A6704 OP_CHECKSIG block.nVersion = 1 block.nTime = 1231006505 block.nBits = 0x1d00ffff block.nNonce = 2083236893 CBlock(hash=000000000019d6, ver=1, hashPrevBlock=00000000000000, hashMerkleRoot=4a5e1e, nTime=1231006505, nBits=1d00ffff, nNonce=2083236893, vtx=1) CTransaction(hash=4a5e1e, ver=1, vin.size=1, vout.size=1, nLockTime=0) CTxIn(COutPoint(000000, -1), coinbase 04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73) CTxOut(nValue=50.00000000, scriptPubKey=0x5F1DF16B2B704C8A578D0B) vMerkleTree: 4a5e1e
The hash of the genesis block, 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f, has two more leading hex zeroes than were required for an early block.
The coinbase parameter (seen above in hex) contains, along with the normal data, the following text:
"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"
This was probably intended as proof that the block was created on or after January 3, 2009, as well as a comment on the instability caused by fractional-reserve banking. Additionally, it suggests that Satoshi Nakamoto may have lived in the United Kingdom
The first 50 BTC block reward went to address 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa though this reward can't be spent due to a quirk in the way that the genesis block is expressed in the code. It is not known if this was done intentionally or accidentally. It is believed that other outputs sent to this address are spendable, but it is unknown if Satoshi Nakamoto has the private key for this particular address, if one existed at all.
Jan 03, 2009
The bitcoin network came into existence with the release of the first open source bitcoin client and the issuance of the first bitcoins, with Satoshi Nakamoto mining the first block of bitcoins ever (known as the genesis block), which had a reward of 50 bitcoins. Embedded in the coinbase of this block was the text:
The Times 03/Jan/2009 Chancellor on brink of second bailout for banks
Block #0, BlockHash 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
BitCoin v0.1.3 ALPHA
Copyright (c) 2009 Satoshi Nakamoto
Distributed under the MIT/X11 software license, see the accompanying file license.txt or http://www.opensource.org/licenses/mit-license.php.
This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/). This product includes cryptographic software written by Eric Young (firstname.lastname@example.org).
Bitcoin is an electronic cash system that uses a peer-to-peer network to prevent double-spending. It's completely decentralized with no server or central authority.
Windows NT/2000/XP (and probably Vista)
Vista hasn't been tested yet. All the libraries used are cross-platform, so there's nothing preventing future Linux and Mac builds.
Unpack the files into a directory and run bitcoin.exe.
The software automatically finds other nodes to connect to. You should set your firewall to forward port 8333 to your computer so you can receive incoming connections, otherwise the nodes you can connect with will be limited.
To support the network by running a node, select:
and keep the program open or minimized. It runs at idle priority when no other programs are using the CPU. Your computer will be solving a very difficult
computational problem that is used to lock in blocks of transactions. The time to generate a block varies each time, but may take days or months, depending on the speed of your computer and the competition on the network. It's not a computation that has to start over from the beginning if you stop and restart it. A solution might be found at any given moment it's running. As a reward for supporting the network, you receive coins when you successfully generate a block.
DR CRAIG S WRIGHT GSE
No. 1: Geek ......... No. 2: Academic Junkie and highly over-qualified for everything (and still in Uni after 22 years...)
Over the years I have published a number of books. These are listed in reverse chronological order below and are linked for further detail. I list those books that are yet to be released first working towards the source and my first publication in the 90's.
Official (ISC)2 Guide to the CISSP(R)-ISSMP(R) CBK
Set to be published 22nd May 2009.
I am the author of the "Law, Investigations, Forensics and Ethics" domain.
Cisco Router and Switch Forensics
Set to be published in early 2009, this book deals with the issues surrounding the forensic analysis of Cisco network devices. I am the author of the chapter on collecting volitile data from Cisco Routers.
Mobile Malware Attacks and Defense
I wrote the section covering the forensic analysis of MMC (Mobile Malware or Mobile Malicious Code). This is the best Book for Analyzing and Mitigating Mobile Malicious Code!
The IT Regulatory and Standards Compliance Handbook: How to Survive Information Systems Audit and Assessments (Paperback)
This is my first attempt at a sole publication. I authored the 750+ pages in this book as a technical guide to Information Technology Audit and Compliance. This publication covers Windows, Unix, Databases, the web, laws and planning and about anything else you can thin k of adding.
Check Point NGX R65 Security Administration
This title is a continuation of Syngress' best-selling references on Check Point's market leading Firewall and VPN products.
The Official CHFI Study Guide (Exam 312-49)
This is the first book I co-authored with Dave Kleiman. The other authors (which I am one) include: Jesse "James" Varsalone and Timothy Clinton.
This is the only official, EC-Council-endorsed CHFI (Computer Hacking Forensics Investigator) study guide. It was written for security professionals, systems administrators, IT consultants, legal professionals, IT managers, police and law enforcement personnel studying for the CHFI certification, and professionals needing the skills to identify an intruder's footprints and properly gather the necessary evidence.
Windows NT Security: Step by Step
The SANS Institute SANS Institute © 2001 (Co-Author)
This book is a little dated now with the depreciation of Windows NT but remains the definative guideline for NT security.
“A Comparative analysis of Firewalls” in “The Internet Hot Sheet”
Having been published in Sept 1999 and initially written in 1998, this book is long forgotten. Few people look for the quantitative history of Firewall products a decade ago. But you never know...
The following books are not yet published. These are on the proverbial drawing board and will be completed in the future.
Finance, Economics and the Security Professional
This is a work in progress. The goal is to create a quantitative framework for modeling IT Security using economics, finance and stochastic control methods (including optimal control estimation). This is still a few years away.
The unified framework modeling book for CIP
This is an ongoing work lead by Bob Radvanovsky' of Infracritical. The expectation is for completion in 2009/2010.
This is my first attempt at writing fiction. I do not have a publisher as yet, but I am open to being contacted by one. I have a number of contacts in the technical writing field, but have not found one in the realm of science fiction as yet.
May 8, 2009
The first post about Bitcoin on Hacker News: https://news.ycombinator.com/item?id=599852
"Well this is an exceptionally cute idea, but there is absolutely no way that anyone is going to have any faith in this currency."
jdoliner on May 9, 2009
@_unwriter (12 Nov 2018)