Kicking the Hornet's Nest - part 5
# Kicking the Hornet's Nest - third edition - part 5
All links, digital (pdf, txt, docx, md) and book in print, can be found at https://hive.blog/@crrdlx/satoshi
Edited by [crrdlx](nostr:nprofile1qyv8wumn8ghj7mn0wdj8y6tkv5hxzurs9aex2mrp0yq3wamnwvaz7tmjv4kxz7fwwpexjmtpdshxuet59uqzqqzmcn0yrn7ttq8hrjkk46ysn2tk26rr8f8k4y7xkl74hlh3rcdzm9d3t8), npub:
```
npub1qpdufhjpel94srm3ett2azgf49m9dp3n5nm2j0rt0l2mlmc3ux3qza082j
```
----
### Kicking the Hornet's Nest pages 75 - 100
----
---------- Forwarded message ----------
From: **Satoshi Nakamoto** <satoshi@vistomail.com>
Date: Tue, Jan 13, 2009 at 2:42 PM
Subject: Re: disk full
To: [hal.finney@gmail.com](mailto:hal.finney@gmail.com)
If you build the dependencies, let me know how that goes.
Everything is always harder to build on Windows than Linux. I've
always hated projects with a lot of big dependencies, but there's
no avoiding it, each one is essential.
I still haven't figured out how you managed to get a read
exception rather than a write exception when your disk filled up.
It's unlikely but maybe possible that the incident could have
messed up your block data file. In that case, it might manifest
as a similar exception again, or if your block count in the status
bar stopped going up, that would also indicate a problem. As of
this moment it's at 375 blocks.
If there is a problem, it could easily be solved by deleting your
block files, as follows:
(exit Bitcoin and make sure it's stopped)
cd /d "%appdata%\bitcoin"
(backup this directory first)
del blk0001.dat
del blkindex.dat
It'll then re-download the block chain. Your transactions and
generated blocks show as 0/unconfirmed until it's done downloading.
The crucial file to backup is wallet.dat. If bitcoin is running
then you have to backup the whole %appdata%\bitcoin directory
including the database subdirectory, but even if it's not running
it certainly feels safer to always backup the whole directory.
The database unfortunately names its files "log.0000000001". To
the rest of the world, "log" means delete-at-will, but to database
people it means delete-and-lose-everything-in-your-other-files. I
tried to put them out of harm's way by putting them in the
database subdirectory. Later I'll write code to flush the logs
after every wallet change so wallet.dat will be standalone safe
almost all the time.
Satoshi
_>Hi Satoshi - Sorry I have not been able to do more today, this looks
>like a busy week for me. I started 0.1.3 again under the MSVC debugger
>this time so if it crashes tonight I may be able to get some more
>information.
>
>I remember now that last night, my disk filled up. I had downloaded a
>bunch of the dependencies (boost, etc) with an eye towards trying to
>build it myself, and my disk was already pretty full. I'm pretty sure
>this is what caused 0.1.3 to crash. I've attached the debug.log, which
>also includes some other runs. The error is about 1/3 of the way down
>and says,
>
>EXCEPTION: NSt8ios_base7failureE
>CAutoFile::read : end of file
>
>Normally this should be a rare occurrence with the large disk sizes
>people have today.
>
>Hal_
## **From satoshi@vistomail.com Tue Jan 13 07:55:20 2009**
From satoshi@vistomail.com Tue Jan 13 07:55:20 2009
Return-Path: <satoshi@vistomail.com>
Delivered-To: dustintrammell-dtrammell@dustintrammell.com
_> It actually posts the hash blocks to a Google Group called_
_> 'proof-hashes', so similar result as if it were posting to Usenet._
_>_
_> http://groups.google.com/group/proof-hashes_
_>_
_> Since I run that group, and it's sole purpose is to archive_
_> proof-of-work hashes, feel free to join an account to have your system_
_> post there as well if you like._
Sweet, I was looking for a group like that on Usenet at one point to see
what I would use if I needed, and nothing really fit. I'm sure Google
groups is a lot easier to post to.
There are some scenarios where a Usenet or Google group could be used as
a supplemental defence. Bitcoin is at its most vulnerable in the
beginning when the total network CPU power is small. That's offset by
the fact that the incentive to attack it is also low when it's small.
Hopefully the easy solution of just growing up and getting past that
stage will work. If not, there are ways a Google group could help, if
it really came to that.
_> Electronic currency and cryptography are two things that I am very_
_> interested in so as you would assume I was drawn to this project_
_> immediately when I saw it posted to the Cryptography email list. Feel_
_> free to ping me for feedback or to test out new features, I'll be happy_
_> to help out._
We definitely have similar interests!
You know, I think there were a lot more people interested in the 90's,
but after more than a decade of failed Trusted Third Party based systems
(Digicash, etc), they see it as a lost cause. I hope they can make the
distinction, that this is the first time I know of that we're trying a
non-trust based system.
_> When the_
_> coins mature, will that generate a new 'credit' transaction, or will the_
_> existing generation transaction line's credit field be updated?_
The existing transaction line will change.
_> Upon opening version 0.1.3, all four of my transaction entries still say_
_> 'unconfirmed', but now the Descriptions say 'Generated (not accepted)'._
_> Does this mean that some other node had extended the chain first and my_
_> coins were generated in a dead branch? If so, why did the previous_
_> instance of the software not detect this immediately and begin_
_> generating coins in the winning branch? Bug in 0.1.0?_
You're right, sorry about that. It's the bug that was fixed in 0.1.3.
The communications thread would get blocked, so you would make
connections, but they would go silent after a while. When you found a
block, you couldn't broadcast it to the network, so it didn't get into
the chain. You weren't receiving anything either to know that the
network had gone on without you, until you restarted it.
The bug is also what caused bitcoin.exe to fail to exit. The
communications thread was blocked and failed to exit. Bitcoin does a
careful shutdown in case it might be in the middle of an important
transaction, but actually it's completely safe to kill it.
This is all fixed in 0.1.3. If you give me your IP, I'll send you some
coins.
_> One other question I had... What prevents the single node with the most_
_> CPU power from generating and retaining the majority of the BitCoins?_
_> If every node is working independently of all others, if one is_
_> significantly more powerful than the others, isn't it probable that this_
_> node will reach the proper conclusion before other nodes? An_
_> underpowered node may get lucky once in a while, but if they are at a_
_> significant horsepower advantage I would expect the majority of BitCoins_
_> to be generated by the most powerful node._
It's not like a race where if one car is twice as fast, it'll always
win. It's an SHA-256 that takes less than a microsecond, and each guess
has an independent chance of success. Each computer's chance of finding
a hash collision is linearly proportional to it's CPU power. A computer
that's half as fast would get half as many coins.
_> I'll watch this instance and see how it goes..._
Let me know how it goes. If you have any trouble with it, send me your
debug.log file. I can often figure out what went wrong just from that.
Satoshi
## **From satoshi@vistomail.com Thu Jan 15 19:15:23 2009**
From satoshi@vistomail.com Thu Jan 15 19:15:23 2009
Return-Path: <satoshi@vistomail.com>
Delivered-To: dustintrammell-dtrammell@dustintrammell.com
_> I've had that address for a while though so hopefully my dhcp_
_> client is being successful at renewing and not losing my address._
_> It does change from time to time, but that address should be good_
_> for a while._
There's at least one node who's inbound IP keeps changing all the
time within the same class B. Maybe every time the program is
run. I wasn't expecting that.
Do you mind if I CC the rest of this to bitcoin-list or
Cryptography?
BTW, bitcoin-list is:
bitcoin-list@lists.sourceforge.net
Subscribe/unsubscribe page:
http://lists.sourceforge.net/mailman/listinfo/bitcoin-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-list
_> Dustin D. Trammell wrote:_
_> > Satoshi Nakamoto wrote:_
_> > You know, I think there were a lot more people interested in the 90's,_
_> > but after more than a decade of failed Trusted Third Party based systems_
_> > (Digicash, etc), they see it as a lost cause. I hope they can make the_
_> > distinction that this is the first time I know of that we're trying a_
_> > non-trust-based system._
_>_
_> Yea, that was the primary feature that caught my eye. The real trick_
_> will be to get people to actually value the BitCoins so that they become_
_> currency._
Hal sort of alluded to the possibility that it could be seen as a
long-odds investment. I would be surprised if 10 years from now
we're not using electronic currency in some way, now that we know
a way to do it that won't inevitably get dumbed down when the TTP
gets cold feet.
Even if it doesn't take off straight away, it's now available for
use by the next guy who comes up with a plan that needs some kind
of token or electronic currency. It could get started in a closed
system or narrow niche like reward points, donation tokens,
currency for a game or micropayments for adult sites. Once it
gets bootstrapped, there are so many applications if you could
effortlessly pay a few cents to a website as easily as dropping
coins in a vending machine.
It can already be used for pay-to-send e-mail. The send dialog is
resizeable and you can enter as long of a message as you like.
It's sent directly when it connects. The recipient doubleclicks
on the transaction to see the full message. If someone famous is
getting more e-mail than they can read, but would still like to
have a way for fans to contact them, they could set up Bitcoin and
give out the IP address on their website. "Send X bitcoins to my
priority hotline at this IP and I'll read the message personally."
Subscription sites that need some extra proof-of-work for their
free trial so it doesn't cannibalize subscriptions could charge
bitcoins for the trial.
Satoshi
## **From satoshi@vistomail.com Thu Jan 15 19:46:35 2009**
From satoshi@vistomail.com Thu Jan 15 19:46:35 2009
Return-Path: <satoshi@vistomail.com>
Delivered-To: dustintrammell-dtrammell@dustintrammell.com
I group attacks into two classes:
1) Attacks that can only be done by someone actually in the chain
of communication
2) Attacks that can be done by anyone on the Internet from anywhere
Type 1 exposes you to people in your house or company on your
local LAN, admins at ISPs in between, and the LAN on the
recipient's side. Type 2 exposes you to a billion people who can
self-select to be attackers and get economy of scale when they
develop one technique to attack multiple victims.
Sending by IP requests a new public key, so yes, it's vulnerable
to type 1 man-in-the-middle. If that's a concern, sending to a
Bitcoin address doesn't have that vulnerability, although there's
a small privacy tradeoff. I have a feeling most of the time
people will get Bitcoin addresses off of non-SSL websites and
unsigned cleartext e-mail, which is already vulnerable to type 1
and type 2 through DNS poisoning.
One solution would be to use both the IP and Bitcoin addresses
when sending (maybe 1.2.3.4-1Kn8iojk...), where the recipient uses
the public key of the Bitcoin address to sign the new public key
to prove that you're sending to who you think you are. If the
system starts to be used for real business purposes, I will
certainly implement that. Another solution is to use SSL.
For now, it's pretty obvious that if you send to an IP, you didn't
give any other identifying information about the recipient, so
you're blindly sending to whoever answers that IP.
Another feature for later is an option to encrypt your wallet.
_> If I understand how that is done correctly, you just compute the_
_> transaction into the block chain and let the intended recipient_
_> 'discover' it, correct?_
That's correct.
_> An alternative could be to allow the network_
_> nodes to provide a resolution service, where they ask around for the_
_> network address of a BitCoin address, and if that node is online, once a_
_> consensus is agreed upon by the network for that address the sending_
_> BitCoin application connects directly there._
It would be nice to only need the Bitcoin address and have the IP
worked out behind the scenes. Might have privacy or denial of
service issues. Certainly before another sending method is
implemented, there's plenty of time now to fully think through the
design and make sure it's the best way.
Satoshi
**Cryptography Mailing List**
Bitcoin v0.1 released
_2009-01-16 16:03:14 UTC_ - [-](http://www.metzdowd.com/pipermail/cryptography/2009-January/015014.html)
> Dustin D. Trammell wrote:
> > Satoshi Nakamoto wrote:
> > You know, I think there were a lot more people interested in the 90's,
> > but after more than a decade of failed Trusted Third Party based systems
> > (Digicash, etc), they see it as a lost cause. I hope they can make the
> > distinction that this is the first time I know of that we're trying a
> > non-trust-based system.
>
> Yea, that was the primary feature that caught my eye. The real trick
> will be to get people to actually value the BitCoins so that they become
> currency.
I would be surprised if 10 years from now we're not using
electronic currency in some way, now that we know a way to do it
that won't inevitably get dumbed down when the trusted third party
gets cold feet.
It could get started in a narrow niche like reward points,
donation tokens, currency for a game or micropayments for adult
sites. Initially it can be used in proof-of-work applications
for services that could almost be free but not quite.
It can already be used for pay-to-send e-mail. The send dialog is
resizeable and you can enter as long of a message as you like.
It's sent directly when it connects. The recipient doubleclicks
on the transaction to see the full message. If someone famous is
getting more e-mail than they can read, but would still like to
have a way for fans to contact them, they could set up Bitcoin and
give out the IP address on their website. "Send X bitcoins to my
priority hotline at this IP and I'll read the message personally."
Subscription sites that need some extra proof-of-work for their
free trial so it doesn't cannibalize subscriptions could charge
bitcoins for the trial.
It might make sense just to get some in case it catches on. If
enough people think the same way, that becomes a self fulfilling
prophecy. Once it gets bootstrapped, there are so many
applications if you could effortlessly pay a few cents to a
website as easily as dropping coins in a vending machine.
Satoshi Nakamoto
http://www.bitcoin.org
## **From satoshi@vistomail.com Fri Jan 16 18:42:18 2009**
From satoshi@vistomail.com Fri Jan 16 18:42:18 2009
Return-Path: <satoshi@vistomail.com>
Delivered-To: dustintrammell-dtrammell@dustintrammell.com
_> One thing that came to mind on this topic is the potential for BitCoin_
_> loss if you have a system failure. The application doesn't seem to_
_> store any data in the directory that it runs in, so I assume it's stored_
_> in the registry and other places (haven't cracked out ProcessExplorer_
_> yet to check myself), so it may be a good idea to have the application_
_> be able to export everything that it needs for recovery to a file that_
_> could be backed up off of the system._
The files are in "%appdata%\Bitcoin", that's the directory to
backup. The data is stored in a transactional database DBM, so
it should be safe from loss if there's a crash or power failure.
%appdata% is per-user access privilege. Most new programs like
Firefox store their settings files there, despite the headwind of
Microsoft changing the directory name with every Windows release
and being full of spaces and so long it runs off the screen.
_> One other thing I noticed today is that if you close the application it_
_> doesn't appear to cleanly close it's network sockets (TCP RST's start_
_> flying). Probably an item for the low-priority todo list (:_
Just now added code to the next release for that.
Satoshi
---------- Forwarded message ----------
From: **Satoshi Nakamoto** <satoshi@vistomail.com>
Date: Sat, Jan 24, 2009 at 4:47 PM
Subject: Re: disk full
To: [hal.finney@gmail.com](mailto:hal.finney@gmail.com)
I hate duplicating code, but the compiler forces us. Copy the body
of the function above it, like this:
void insert(iterator it, const_iterator first, const_iterator last)
{
if (it == vch.begin() + nReadPos && last - first <= nReadPos)
{
// special case for inserting at the front when there's room
nReadPos -= (last - first);
memcpy(&vch[nReadPos], &first[0], last - first);
}
else
vch.insert(it, first, last);
}
#if !defined(_MSC_VER) || _MSC_VER >= 1300
void insert(iterator it, const char* first, const char* last)
{
if (it == vch.begin() + nReadPos && last - first <= nReadPos)
{
// special case for inserting at the front when there's room
nReadPos -= (last - first);
memcpy(&vch[nReadPos], &first[0], last - first);
}
else
vch.insert(it, first, last);
}
#endif
The modified version of serialize.h is attached.
BTW, in my tests, VC8 produced an EXE that would only run on
systems that had VC8 installed on them. The error it gives
is extremely vague. I think they expect you to install a
package during setup, but bitcoin doesn't have a setup.
My testing has been with MSVC 6.0 SP6 and GCC 3.4.5.
GCC is the release build. There's nothing wrong with the
MSVC 6.0 build other than its optimization of the SHA routines
for generating blocks is slow.
Satoshi
## **From satoshi@vistomail.com Sun Jan 18 17:01:09 2009**
From satoshi@vistomail.com Sun Jan 18 17:01:09 2009
Return-Path: <satoshi@vistomail.com>
Delivered-To: dustintrammell-dtrammell@dustintrammell.com
It should be your Bitcoin address at home that you received it
with. There's no way for it to know who it's from, so the best
it can do is tell which of your addresses it was received on.
You can create multiple addresses and give a different address
to each person and label them to help figure out who's sending
to you.
It doesn't know any names other than what you tell it. The name
printed there is what's associated in your address book for that
address, either under the Address Book button or the "Change..."
button to the right of your Bitcoin address.
_>Hey Satoshi,_
_>_
_>After that first transfer of 25.00, you didn't send me another 100.00_
_>did you? I sent myself 100.00 from my BitCoin application at work to my_
_>one at home using the BitCoin address rather than by IP. My application_
_>at home has a 100.00 transfer received, however it's transaction details_
_>say "Received with: Satoshi 12higDjoCCNXSA95xZMWUdPvXNmkAduhWv". That_
_>is not my BitCoin address from work, so I assume this means that I_
_>received the payment encoded with a block that was computed by your_
_>client? If so, how did it know your name in addition to the BitCoin_
_>address that generated it? I don't recall there being a place in my_
_>application to even put my name._
_>_
_>--_
_>Dustin D. Trammell_
_>dtrammell@dustintrammell.com_
_>http://www.dustintrammell.com_
_>_
## **From satoshi@vistomail.com Mon Jan 19 17:02:37 2009**
From satoshi@vistomail.com Mon Jan 19 17:02:37 2009
Return-Path: <satoshi@vistomail.com>
Delivered-To: dustintrammell-dtrammell@dustintrammell.com
_>On Mon, 2009-01-19 at 00:54 +0800, Satoshi Nakamoto wrote:_
_>> It should be your Bitcoin address at home that you received it_
_>> with. There's no way for it to know who it's from, so the best_
_>> it can do is tell which of your addresses it was received on._
_>> You can create multiple addresses and give a different address_
_>> to each person and label them to help figure out who's sending_
_>> to you._
_>_
_>Ah! I didn't even notice it was my address at home, you're right (: I_
_>do have multiple addresses created at home so I didn't make the_
_>connection._
_>_
_>> It doesn't know any names other than what you tell it. The name_
_>> printed there is what's associated in your address book for that_
_>> address, either under the Address Book button or the "Change..."_
_>> button to the right of your Bitcoin address._
_>_
_>Ahh you're right, 'Satoshi' is associated with the address that received_
_>the payment under the Change button's addresses. I don't recall setting_
_>that value though, is that the default or something? (this is the first,_
_>default, address that the application generated itself when I first ran_
_>it)_
The first default one is labelled "Your Address" when it's created.
All the places where address book labels are set are where the user manually sets it. The only time it automatically adds a label is a blank one when you send to a new address. I guess you could have entered the label on an address you thought was mine but the software was confusing and you put it in the wrong place.
Address book labels for receiving addresses is confusing but I'm not sure what else to do. Anyone using it for more than just simple purposes would need to create different receiving addresses for each payer so they could tell who's paying them. That concept doesn't have much analogy in the real world.
Satoshi
**Cryptography Mailing List**
Bitcoin v0.1 released
_2009-01-25 15:47:10 UTC_ - [-](http://www.metzdowd.com/pipermail/cryptography/2009-January/015041.html)
Hal Finney wrote:
> > * Spammer botnets could burn through pay-per-send email filters
> > trivially
> If POW tokens do become useful, and especially if they become money,
> machines will no longer sit idle. Users will expect their computers to
> be earning them money (assuming the reward is greater than the cost to
> operate). A computer whose earnings are being stolen by a botnet will
> be more noticeable to its owner than is the case today, hence we might
> expect that in that world, users will work harder to maintain their
> computers and clean them of botnet infestations.
Another factor that would mitigate spam if POW tokens have value:
there would be a profit motive for people to set up massive
quantities of fake e-mail accounts to harvest POW tokens from
spam. They'd essentially be reverse-spamming the spammers with
automated mailboxes that collect their POW and don't read the
message. The ratio of fake mailboxes to real people could become
too high for spam to be cost effective.
The process has the potential to establish the POW token's value
in the first place, since spammers that don't have a botnet could
buy tokens from harvesters. While the buying back would
temporarily let more spam through, it would only hasten the
self-defeating cycle leading to too many harvesters exploiting the
spammers.
Interestingly, one of the e-gold systems already has a form of
spam called "dusting". Spammers send a tiny amount of gold dust
in order to put a spam message in the transaction's comment field.
If the system let users configure the minimum payment they're
willing to receive, or at least the minimum that can have a
message with it, users could set how much they're willing to get
paid to receive spam.
Satoshi Nakamoto
**bitcoin-list**
Re: [**bitcoin-list**] Problems
_2009-01-25 16:45:25 UTC_ - [-](https://sourceforge.net/p/bitcoin/mailman/message/21424626/)
From: Nicholas Bohm 2009-01-25 10:17
> I have had a couple of problems running bitcoin: is this an appropriate
> list for reporting them (with about 70kb of attachments)?
What's the problem you're having?
If you send me your debug.log file directly (best not to send attachments
to the list), I can take a look at what's happening.
Satoshi Nakamoto
bitcoin-help at vistomail dot com
**bitcoin-list**
[**bitcoin-list**] Bitcoin v0.1.5 released
_2009-02-04 19:46:04 UTC_ - [-](https://sourceforge.net/p/bitcoin/mailman/message/21500063/)
Version 0.1.5 is now available. It includes the fix for the problem
Nicholas had, checking for disk full and changes to try to improve
things that were confusing.
Special thanks to Nicholas and Dustin for all their help and feedback!
Download link:
http://sourceforge.net/project/showfiles.php?group_id=244765&package_id=298441
Changes:
- disk full warning
- fixed a bug that could occur if dns lookup failed
- prevent entering your own address in the address book,
which confusingly changed the label for your own address
- moved change address button to menu under options
- tweaks to make it get connected faster
- close sockets on exit
- created minimum fee for transactions less than 1 cent
- hid the transaction-type selection box that only had one choice
- cleaned up ParseMoney a little
- slightly cleaner reformatting of message text
- changed the font in transaction details dialog
- added some explanation text to transaction details for generated coins
- reworded the description for transactions received with bitcoin address
Satoshi Nakamoto
http://www.bitcoin.org
**P2P Foundation**
Bitcoin open source implementation of P2P currency
_2009-02-11 22:27:00 UTC_ - [-](http://p2pfoundation.ning.com/forum/topics/bitcoin-open-source)
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](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](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.
Satoshi Nakamoto
[http://www.bitcoin.org](http://www.bitcoin.org/)
**P2P Foundation**
Bitcoin open source implementation of P2P currency
_2009-02-15 16:42:00 UTC_ - [-](http://p2pfoundation.ning.com/xn/detail/2003008:Comment:9493)
Could be. They're talking about the old Chaumian central mint stuff, but maybe only because that was the only thing available. Maybe they would be interested in going in a new direction.
A lot of people automatically dismiss e-currency as a lost cause because of all the companies that failed since the 1990's. I hope it's obvious it was only the centrally controlled nature of those systems that doomed them. I think this is the first time we're trying a decentralized, non-trust-based system.
**P2P Foundation**
Bitcoin open source implementation of P2P currency
_2009-02-18 20:50:00 UTC_ - [-](http://p2pfoundation.ning.com/xn/detail/2003008:Comment:9562)
It is a global distributed database, with additions to the database by consent of the majority, based on a set of rules they follow:
- Whenever someone finds proof-of-work to generate a block, they get some new coins
- The proof-of-work difficulty is adjusted every two weeks to target an average of 6 blocks per hour (for the whole network)
- The coins given per block is cut in half every 4 years
You could say coins are issued by the majority. They are issued in a limited, predetermined amount.
As an example, if there are 1000 nodes, and 6 get coins each hour, it would likely take a week before you get anything.
To Sepp's question, indeed there is nobody to act as central bank or federal reserve to adjust the money supply as the population of users grows. That would have required a trusted party to determine the value, because I don't know a way for software to know the real world value of things. If there was some clever way, or if we wanted to trust someone to actively manage the money supply to peg it to something, the rules could have been programmed for that.
In this sense, it's more typical of a precious metal. 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, which could attract more users to take advantage of the increasing value.
**bitcoin-list**
Re: [**bitcoin-list**] Bitcoin v0.1.5 released
_2009-02-22 17:47:52 UTC_ - [-](https://sourceforge.net/p/bitcoin/mailman/message/21646307/)
> What's next?
The next thing for v0.1.6 is to take advantage of multiple
processors to generate blocks. Currently it only starts one
thread. If you have a multi-core processor like a Core Duo or
Quad this will double or quadruple your production.
Later I want to add interfaces to make it really easy to integrate
into websites from any server side language.
Satoshi
http://www.bitcoin.org
**bitcoin-list**
Re: [**bitcoin-list**] Bitcoin v0.1.5 released
_2009-03-04 16:59:12 UTC_ - [-](https://sourceforge.net/p/bitcoin/mailman/message/21740046/)
Hal Finney wrote:
> That sounds good. I'd also like to be able to run multiple coin/block
> generators on multiple machines, all behind a single NAT address. I
> haven't tried this yet so I don't know if it works on the current
> software.
The current version will work fine. They'll each connect over the
Internet, while incoming connections only come to the host that
port 8333 is routed to.
As an optimisation, I'll make a switch "-connect=1.2.3.4" to make
it only connect to a specific address. You could make your extra
nodes connect to your primary, and only the primary connects over
the Internet. It doesn't really matter for now, since the network
would have to get huge before the bandwidth is anything more than
trivial.
> BTW I don't remember if we talked about this, but the other day some
> people were mentioning secure timestamping. You want to be able to
> prove that a certain document existed at a certain time in the past.
> Seems to me that bitcoin's stack of blocks would be perfect for this.
Indeed, Bitcoin is a distributed secure timestamp server for
transactions. A few lines of code could create a transaction with
an extra hash in it of anything that needs to be timestamped.
I should add a command to timestamp a file that way.
> > > Later I want to add interfaces to make it really easy to integrate
> > > into websites from any server side language.
>
> Right, and I'd like to see more of a library interface that could be
> called from programming or scripting languages, on the client side as
> well.
Exactly.
Satoshi Nakamoto
http://www.bitcoin.org
**Mike Hearn** <mike@plan99.net>
Sun, Apr 12, 2009 at 12:46 PM
To: satoshin@gmx.com
Hi Satoshi,
I read your paper on BitCoin with great interest. I found it a bit
confusing though - I believe it may be easier to follow if you provide
some examples.
Specifically, it's not quite clear to me what blocks contain. If I
understand correctly, there is only one (or maybe a few) global
chain[s] into which all transactions are hashed. If there is only one
chain recording "the story of the economy" so to speak, how does this
scale? In an imaginary planet-wide deployment there would be millions
of even billions of transactions per hour being hashed into the chain.
I realize that each PoW can wrap many transactions in one block,
nonetheless, that's a large amount of data to hash. If there are many
chains, how are transactions assigned to each chain such that it is
still difficult to overpower the network? Eg, if there are 10 global
chains, the amount of cpu power you need to beat the system is only
10% of what it was previously.
I also wonder if the assumption of 1 core = 1 vote is sound. If the
majority of nodes are on standard computers, it seems likely that an
attacker could use FPGA or custom ASICs to get significantly better
performance. What are your thoughts on using custom hardware to beat
the chain?
I found the section on incentives hard to follow. In particular, I'm
not clear on what triggers the transition from minting new coins as a
reason to run a node, to charging transaction fees (isn't the point of
BitCoin largely to zero transaction costs anyway?). Presumably there's
some human in charge of the system - eg, you decided somehow that 24
million coins was a good number to have, and would distribute some
kind of rules file saying "coins minted after this timestamp must have
an N+1 zero bits prefix", which honest nodes enforce.
How did you decide on the inflation schedule for v1? Where did 24
million coins come from? What denominations are these coins? You
mention a way to combine and split value but I'm not clear on how this
works. For instance are bitcoins always denominated by an integer or
can you have fractional bitcoins?
So many questions :) But it's rare that I encounter truly
revolutionary ideas. The last time I was this excited about a new
monetary scheme was when I discovered Ripple. If you have any thoughts
on Ripple, I'd also love to hear them.
thanks -mike
**Satoshi Nakamoto** <satoshin@gmx.com>
Sun, Apr 12, 2009 at 10:44 PM
To: Mike Hearn <mike@plan99.net>
Hi Mike,
I'm glad to answer any questions you have. If I get time, I ought to write a FAQ to supplement the paper.
There is only one global chain.
The existing Visa credit card network processes about 15 million Internet purchases per day worldwide. Bitcoin can already scale much larger than that with existing hardware for a fraction of the cost. It never really hits a scale ceiling. If you're interested, I can go over the ways it would cope with extreme size.
By Moore's Law, we can expect hardware speed to be 10 times faster in 5 years and 100 times faster in 10. Even if Bitcoin grows at crazy adoption rates, I think computer speeds will stay ahead of the number of transactions.
I don't anticipate that fees will be needed anytime soon, but if it becomes too burdensome to run a node, it is possible to run a node that only processes transactions that include a transaction fee. The owner of the node would decide the minimum fee they'll accept. Right now, such a node would get nothing, because nobody includes a fee, but if enough nodes did that, then users would get faster acceptance if they include a fee, or slower if they don't. The fee the market would settle on should be minimal. If a node requires a higher fee, that node would be passing up all transactions with lower fees. It could do more volume and probably make more money by processing as many paying transactions as it can. The transition is not controlled by some human in charge of the system though, just individuals reacting on their own to market forces.
Eventually, most nodes may be run by specialists with multiple GPU cards. For now, it's nice that anyone with a PC can play without worrying about what video card they have, and hopefully it'll stay that way for a while. More computers are shipping with fairly decent GPUs these days, so maybe later we'll transition to that.
A key aspect of Bitcoin is that the security of the network grows as the size of the network and the amount of value that needs to be protected grows. The down side is that it's vulnerable at the beginning when it's small, although the value that could be stolen should always be smaller than the amount of effort required to steal it. If someone has other motives to prove a point, they'll just be proving a point I already concede.
My choice for the number of coins and distribution schedule was an educated guess. It was a difficult choice, because once the network is going it's locked in and we're stuck with it. I wanted to pick something that would make prices similar to existing currencies, but without knowing the future, that's very hard. I ended up picking something in the middle. If Bitcoin remains a small niche, it'll be worth less per unit than existing currencies. If you imagine it being used for some fraction of world commerce, then there's only going to be 21 million coins for the whole world, so it would be worth much more per unit. Values are 64-bit integers with 8 decimal places, so 1 coin is represented internally as 100000000. There's plenty of granularity if typical prices become small. For example, if 0.001 is worth 1 Euro, then it might be easier to change where the decimal point is displayed, so if you had 1 Bitcoin it's now displayed as 1000, and 0.001 is displayed as 1.
Ripple is interesting in that it's the only other system that does something with trust besides concentrate it into a central server.
Satoshi
[Quoted text hidden]
**Mike Hearn** <mike@plan99.net>
Mon, Apr 13, 2009 at 1:39 PM
To: Satoshi Nakamoto <satoshin@gmx.com>
Thanks Satoshi,
I tried the app yesterday. It seems to work pretty well running on
Wine (I tried it on MacOS but it should run on Linux too, and will try
that next week when I am back at work).
In the lower right hand corner it has a block count which increases
rapidly and then stops. Is this the length of the global chain? It
seems to advance far too fast for that. Or is this the number of
genesis blocks that have been tried but did not result in a partial
collision? I'm not sure if the way it stops and starts is expected, or
some glitch caused by it running under emulation. My best guess - it
is the length of the global chain, and the rapid advance at the start
is as the software downloads and verifies the preceding blocks in the
chain as being valid.
With regards to the buyer/seller experience, I understand that the
global chain advances at about 6-7 blocks per hour under the current
settings. If we assume that 0.1% is a good risk rate, then z=5 thus
any transaction must wait a bit less than an hour before being
solidified in the chain. As micropayments for things like web content
or virtual goods are by definition something that requires low
overhead, waiting an hour seems like quite a significant hurdle.
I understand that nodes attempt to find a POW to advance the global
chain in an uncoordinated fashion. This sentence however:
"If a majority of CPU power is controlled by honest nodes, the
honest chain will grow the fastest and outpace any competing chains."
is confusing for me, because it appears the only way the honest chain
can grow faster than a chain worked on by 1 attacking cpu is if the
keyspace to scan looking for a partial collision is sharded evenly
amongst the participating honest nodes. That way the speed at which
collisions are found would be proportional to the number of nodes. Yet
I don't see any discussion of such work sharding, which obviously adds
complexity. Likewise:
"To compensate for increasing hardware speed and varying interest
in running nodes over time,
the proof-of-work difficulty is determined by a moving average
targeting an average number of
blocks per hour. If they're generated too fast, the difficulty increases."
How is the required difficulty of each block communicated through the
network and agreed upon?
Thanks once again. I have yet more questions but this is enough for
one email :) I will be happy to summarize these discussions into an
FAQ-like document at some point. Apologies if the questions seem
trivial.
-mike
[Quoted text hidden]
**Mike Hearn** <mike@plan99.net>
Mon, Apr 13, 2009 at 10:51 PM
To: Satoshi Nakamoto <satoshin@gmx.com>
Something else that isn't clear to me - does the global chain only get
extended when there is actual work to do? Currently it seems to grow
all the time, although there are only a few people in the network. So
presumably it gets extended with null blocks. Is this actually
required? The timestamping doesn't have to be actually in parallel
with real time does it ... it's merely establishing an ordering of
events.
[Quoted text hidden]
**Satoshi Nakamoto** <satoshin@gmx.com>
Mon, Apr 13, 2009 at 11:00 PM
To: Mike Hearn <mike@plan99.net>
Mike Hearn wrote:
My best guess - it
is the length of the global chain, and the rapid advance at the start
is as the software downloads and verifies the preceding blocks in the
chain as being valid.
Right. I'm trying to think of more clear wording for that, maybe "%d network blocks" or "%d block chain".
If we assume that 0.1% is a good risk rate, then z=5 thus
any transaction must wait a bit less than an hour before being
solidified in the chain. As micropayments for things like web content
or virtual goods are by definition something that requires low
overhead, waiting an hour seems like quite a significant hurdle.
For the actual risk, multiply the 0.1% by the probability that the buyer is an attacker with a huge network of computers.
For micropayments, you can safely accept the payment immediately. The size of the payment is too small for the effort to steal it. Micropayments are almost always for intellectual property, where there's no physical loss to the merchant. Anyone trying to steal a micropayment would probably not be a paying customer anyway, and if they want to steal intellectual property they can use the file sharing networks.
Currently, businesses accept a certain chargeoff rate. I believe the risk with 1 or even 0 confirming blocks will be much less than the rate of chargebacks on verified credit card transactions.
The usual scam against a merchant that doesn't wait for confirming blocks would be to send a payment to a merchant, then quickly try to propagate a double-spend to the network before the merchant's copy. What the merchant can do is broadcast his transaction and then monitor the network for any double-spend copies. The thief would not be able to broadcast during the monitoring period or else the merchant's node would receive a copy. The merchant would only have to monitor for a minute or two until most of the network nodes have his version and it's too late for the thief's version to catch up and reach many nodes. With just a minute or two delay, the chance of getting away without paying could be made much too low to scam. A thief usually needs a high probability of getting an item for free to make it worthwhile. Using a lot of CPU power to do the brute force attack discussed in the paper in addition to the above scam would not increase the thief's chances very much.
Anything that grants access to something, like something that takes a while to download, access to a website, web hosting, a subscription or service, can be cancelled a few minutes later if the transaction is rejected.
is confusing for me, because it appears the only way the honest chain
can grow faster than a chain worked on by 1 attacking cpu is if the
keyspace to scan looking for a partial collision is sharded evenly
amongst the participating honest nodes. That way the speed at which
collisions are found would be proportional to the number of nodes. Yet
I don't see any discussion of such work sharding, which obviously adds
complexity.
The keyspace is huge, 2^256. The thing being hashed includes the node's public key and a random nonce, so the chance of any two nodes duplicating work on the same space is negligible.
How is the required difficulty of each block communicated through the
network and agreed upon?
It's not communicated. The formula is hardcoded in the program and every node does the same calculation to know what difficulty is required for the next block. If someone diverged from the formula, their block would not be accepted by the majority.
Thanks once again. I have yet more questions but this is enough for
one email :) I will be happy to summarize these discussions into an
FAQ-like document at some point. Apologies if the questions seem
trivial.
No problem, thanks for testing it on Mac Wine.
Satoshi
[Quoted text hidden]
**Satoshi Nakamoto** <satoshin@gmx.com>
Mon, Apr 13, 2009 at 11:11 PM
To: Mike Hearn <mike@plan99.net>
It keeps getting extended all the time. If it stopped, an attacker would have time to catch up. Don't worry, empty blocks aren't very big.
As you say, it's the order of events that matters.
[Quoted text hidden]
**Mike Hearn** <mike@plan99.net>
Mon, Apr 13, 2009 at 11:18 PM
To: Satoshi Nakamoto <satoshin@gmx.com>
Oh yes, of course, that's fundamental. Silly me. Thanks for your
answers. I'd recommend being over-explicit for early versions of the
software, something like "Global chain is currently %d blocks long".
I guess the key problem right now is that once you generate coins,
there's nobody to test it with, even for dummy transactions. Is there
a plan for a mailing list or some kind of trivial marketplace to give
people something to do with their newly minted bitcoins?
**Satoshi Nakamoto** <satoshin@gmx.com>
Tue, Apr 14, 2009 at 7:41 PM
To: Mike Hearn <mike@plan99.net>
I started implementing a marketplace feature earlier that facilitates offering things for sale and taking orders, it's only half done though. A bit like e-bay but without auctions, just "buy now". Among other things, it would make it easy for anyone to offer currency exchange.
If you send to 1PhUXucRd8FzQved2KGK3g1eKfTHPGjgFu and e-mail me your bitcoin address, or IP if you can accept incoming connections, I'll send back the same amount +50.
[Quoted text hidden]
**Mike Hearn** <mike@plan99.net>
Sat, Apr 18, 2009 at 3:08 PM
To: Satoshi Nakamoto <satoshin@gmx.com>
Hi Satoshi,
I sent you 32.51 coins, my bitcoin address is 1JuEjh9znXwqsy5RrnKqgzqY4Ldg7rnj5n
My IP is currently 84.73.233.199, however, it's a laptop so may or may
not be online at the time you act on this mail. I suggest using the
bitcoin address instead. It'd be convenient if the same comment
functionality was available via indirect transfer. Can the comment be
encrypted using the public key of the receiver and placed into a
block?
[Quoted text hidden]
----
