Kicking the Hornet's Nest - part 21
# Kicking the Hornet's Nest - third edition - part 21
All links, digital (pdf, txt, docx, md) and book in print, can be found at https://hive.blog/@crrdlx/satoshi
Edited by [crrdlx](@crrdlx), npub:
```
npub1qpdufhjpel94srm3ett2azgf49m9dp3n5nm2j0rt0l2mlmc3ux3qza082j
```
### Kicking the Hornet's Nest pages 475 - 506
Martii Malmi (AKA Sirius) “COPA trial” email #241
Date: Fri, 03 Dec 2010 19:58:40 +0000
From: Satoshi Nakamoto <satoshin@gmx.com>
Subject: Re: What was the bitcoin.org outage?
To: mmalmi@cc.hut.fi
> I told him to go ahead. I don't do automatic backups atm. We should have
> more server admins soon when I get bitcoinexchange.com to another
> server. I could give the root password to you and somebody else. Xunie
> has volunteered, but we might find somebody even more professional from
> the forum and keep the number of admins at the minimum. If the outage
> was due to heavy load, he could help us move to lighttpd or optimize
> resources otherwise. Should we make a recruitment thread on the forum?
It should be Gavin. I trust him, he's responsible, professional, and
technically much more linux capable than me.
(I don't know Xunie, but he hasn't posted for months and he was a goofball)
##### BitcoinTalk
#### Re: Wikileaks contact info?
##### 2010-12-05 09:08:08 UTC - [-](https://bitcointalk.org/index.php?topic=1735.msg26999#msg26999)
[Quote from: RHorning on December 04, 2010, 10:17:44 PM](https://bitcointalk.org/index.php?topic=1735.msg26876#msg26876)
Basically, bring it on. Let's encourage Wikileaks to use Bitcoins and I'm willing to face any risk or fallout from that act.
No, don't "bring it on".
The project needs to grow gradually so the software can be strengthened along the way.
I make this appeal to WikiLeaks not to try to use Bitcoin. Bitcoin is a small beta community in its infancy. You would not stand to get more than pocket change, and the heat you would bring would likely destroy us at this stage.
Martii Malmi (AKA Sirius) “COPA trial” email #243
Date: Mon, 06 Dec 2010 16:08:56 +0000
From: Satoshi Nakamoto <satoshin@gmx.com>
Subject: Re: What was the bitcoin.org outage?
To: mmalmi@cc.hut.fi
mmalmi@cc.hut.fi wrote:
> I'm ready to send you the password. Can you send me your PGP key so I
> don't have to send it in plaintext?
>
>> It should be Gavin. I trust him, he's responsible, professional, and
>> technically much more linux capable than me.
>
> Ok, I'll ask him.
Thanks, did you finish moving bitcoinexchange to another server?
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.7 (MingW32)
mQGiBEkJ+qcRBADKDTcZlYDRtP1Q7/ShuzBJzUh9hoVVowogf2W07U6G9BqKW24r
piOxYmErjMFfvNtozNk+33cd/sq3gi05O1IMmZzg2rbF4ne5t3iplXnNuzNh+j+6
VxxA16GPhBRprvnng8r9GYALLUpo9Xk17KE429YYKFgVvtTPtEGUlpO1EwCg7FmW
dBbRp4mn5GfxQNT1hzp9WgkD/3pZ0cB5m4enzfylOHXmRfJKBMF02ZDnsY1GqeHv
/LjkhCusTp2qz4thLycYOFKGmAddpVnMsE/TYZLgpsxjrJsrEPNSdoXk3IgEStow
mXjTfr9xNOrB20Qk0ZOO1mipOWMgse4PmIu02X24OapWtyhdHsX3oBLcwDdke8aE
gAh8A/sHlK7fL1Bi8rFzx6hb+2yIlD/fazMBVZUe0r2uo7ldqEz5+GeEiBFignd5
HHhqjJw8rUJkfeZBoTKYlDKo7XDrTRxfyzNuZZPxBLTj+keY8WgYhQ5MWsSC2MX7
FZHaJddYa0pzUmFZmQh0ydulVUQnLKzRSunsjGOnmxiWBZwb6bQjU2F0b3NoaSBO
YWthbW90byA8c2F0b3NoaW5AZ214LmNvbT6IYAQTEQIAIAUCSQn6pwIbAwYLCQgH
AwIEFQIIAwQWAgMBAh4BAheAAAoJEBjAnoZeyUihXGMAnjiWJ0fvmSgSM3o6Tu3q
RME9GN7QAKCGrFw9SUD0e9/YDcqhX1aPMrYue7kCDQRJCfqnEAgA9OTCjLa6Sj7t
dZcQxNufsDSCSB+yznIGzFGXXpJk7GgKmX3H9Zl4E6zJTQGXL2GAV4klkSfNtvgs
SGJKqCnebuZVwutyq1vXRNVFPQFvLVVo2jJCBHWjb03fmXmavIUtRCHoc8xgVJMQ
LrwvS943GgsqSbdoKZWdTnfnEq+UaGo+Qfv66NpT3Yl0CXUiNBITZOJcJdjHDTBO
XRqomX2WSguv+btYdhQGGQiaEx73XMftXNCxbOpqwsODQns7xTcl2ENru9BNIQME
I7L9FYBQUiKHm1k6RrBy1as8XElS2jEos7GAmlfF1wShFUX+NF1VOPdbN3ZdFoWq
sUjKk+QbrwADBQgA9DiD4+uuRhwk2B1TmtrXnwwhcdkE7ZbLHjxBfCsLPAZiPh8c
ICfV3S418i4H1YCz2ItcnC8KAPoS6mipyS28AU1B7zJYPODBn8E7aPSPzHJfudMK
MqiCHljVJrE23xsKTC0sIhhSKcr2G+6ARoG5lwuoqJqEyDrblVQQFpVxBNPHSTqu
O5PoLXQc7PKgC5SyQuZbEALEkItl2SL2yBRRGOlVJLnvZ6eaovkAlgsbGdlieOr0
UwWuJCwzZuBDruMYAfyQBvYfXZun3Zm84rW7Jclp18mXITwGCVHg/P5n7QMbBfZQ
A25ymkuj636Nqh+c4zRnSINfyrDcID7AcqEb6IhJBBgRAgAJBQJJCfqnAhsMAAoJ
EBjAnoZeyUihPrcAniVWl5M44RuGctJe+IMNX4eVkC08AJ9v7cXsp5uDdQNo8q3R
8RHwN4Gk8w==
=3FTe
-----END PGP PUBLIC KEY BLOCK-----
It's also at
http://www.bitcoin.org/Satoshi_Nakamoto.asc
Martii Malmi (AKA Sirius) “COPA trial” email #245
Date: Tue, 07 Dec 2010 15:38:28 +0000
From: Satoshi Nakamoto <satoshin@gmx.com>
Subject: Project Developers
To: Martti Malmi <mmalmi@cc.hut.fi>
Mind if I add you to the Project Developers list on the Contact page?
You wrote some code before so you should be there. It would have to be
your real name for consistency. If you want to have an e-mail address
listed, I'll make an image out of it so it doesn't attract spam.
##### BitcoinTalk
#### Re: JSON-RPC method idea: list transactions newer than a given txid
##### 2010-12-08 20:21:49 UTC - [-](https://bitcointalk.org/index.php?topic=2151.msg28228#msg28228)
It's not safe to use listtransactions this way.
I know I've been criticized for being reluctant about listtransactions. Let me explain my reluctance.
Transactions are dynamic. Past transactions can become unconfirmed, go away and come back, become invalid and disappear, or be replaced by a different double-spend. Their date can change, their order can change.
Programmers are naturally inclined to want to use listtransactions like this: feed me the new transactions since I last asked, and I'll keep my own tally or static record of them. This will seem to work in all regular use, but if you use the amounts for anything, it is highly exploitable:
1) How do you know if a past transaction becomes invalid and disappears?
2) When there's a block-chain reorg, it would be easy to double-count transactions when they get confirmed again.
3) A transaction can be replaced by a double-spend with a different txid. You would count both spends.
The model where you assume you only need to see new transactions because you've already seen previous transactions is not true. Old transactions can change at any time.
Any time you take an action based on payment amounts received, you always need to go back to bitcoin and ask for a current balance total (or use move or sendfrom), and be ready for the possibility that it can go down.
Now that we have the Accounts feature making it easier to do it the right way, we're better prepared to have listtransactions.
##### BitcoinTalk
#### Re: JSON-RPC method idea: list transactions newer than a given txid
##### 2010-12-08 22:36:45 UTC - [-](https://bitcointalk.org/index.php?topic=2151.msg28292#msg28292)
Then how do you cope with the issues I listed in the message you quoted?
bitcoin-list
[bitcoin-list] Bitcoin 0.3.18 is released
2010-12-08 23:11:55 UTC - [-](https://sourceforge.net/p/bitcoin/mailman/message/26722835/)
Version 0.3.18 is now available.
Changes:
- Fixed a wallet.dat compatibility problem if you downgraded from 0.3.17
and then upgraded again
- IsStandard() check to only include known transaction types in blocks
- Jgarzik's optimisation to speed up the initial block download a little
The main addition in this release is the Accounts-based JSON-RPC
commands that Gavin's been working on (more details at
http://www.bitcoin.org/smf/index.php?topic=1886.0).
- getaccountaddress
- sendfrom
- move
- getbalance
- listtransactions
Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.18/
##### BitcoinTalk
#### Version 0.3.18
##### 2010-12-08 23:19:24 UTC - [-](https://bitcointalk.org/index.php?topic=2162.msg28302#msg28302)
Changes:
- Fixed a wallet.dat compatibility problem if you downgraded from 0.3.17 and then upgraded again
- IsStandard() check to only include known transaction types in blocks
- Jgarzik's optimisation to speed up the initial block download a little
The main addition in this release is the Accounts-Based JSON-RPC commands that Gavin's been working on (more details at [http://BitcoinTalk.org/index.php?topic=1886.0](http://bitcointalk.org/index.php?topic=1886.0)).
- getaccountaddress
- sendfrom
- move
- getbalance
- listtransactions
Download:
[http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.18/](http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.18/)
Martii Malmi (AKA Sirius) “COPA trial” email #247
Date: Wed, 08 Dec 2010 23:09:45 +0000
From: Satoshi Nakamoto <satoshin@gmx.com>
Subject: [bitcoin-list] Bitcoin 0.3.18 is released
To: bitcoin-list@lists.sourceforge.net
Version 0.3.18 is now available.
Changes:
- Fixed a wallet.dat compatibility problem if you downgraded from 0.3.17
and then upgraded again
- IsStandard() check to only include known transaction types in blocks
- Jgarzik's optimisation to speed up the initial block download a little
The main addition in this release is the Accounts-based JSON-RPC
commands that Gavin's been working on (more details at
http://www.bitcoin.org/smf/index.php?topic=1886.0).
- getaccountaddress
- sendfrom
- move
- getbalance
- listtransactions
Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.18/
##### BitcoinTalk
#### Re: JSON-RPC method idea: list transactions newer than a given txid
##### 2010-12-09 00:12:17 UTC - [-](https://bitcointalk.org/index.php?topic=2151.msg28313#msg28313)
I'm not talking about the normal risk for a given minconf level, I'm talking about additional pitfalls from listtransactions when used this way.
[Quote from: satoshi on December 08, 2010, 10:36:45 PM](https://bitcointalk.org/index.php?topic=2151.msg28292#msg28292)
2) When there's a block-chain reorg, it would be easy to double-count transactions when they get confirmed again.
The OP's example of listtransactions <account> [count=10] [txid] seems to imply and it would be very easy for programmers to assume that if they pass in the last txid of the previous call to listtransactions, they will never see the same transaction more than once, which is not the case. It would be very easy to double-count payments if you don't maintain your own persistent map or dictionary to track which txid's you've already accepted.
It doesn't seem right to have a function that seems tailor made to be used a certain obvious way, and that way is a non-obvious trap.
[Quote from: jgarzik on December 08, 2010, 11:07:22 PM](https://bitcointalk.org/index.php?topic=2151.msg28301#msg28301)
[Quote from: satoshi on December 08, 2010, 10:36:45 PM](https://bitcointalk.org/index.php?topic=2151.msg28292#msg28292)
3) A transaction can be replaced by a double-spend with a different txid. You would count both spends.
listtransactions does not add anything to this problem, beyond that which is already vulnerable through listreceivedbyaddress.
Suppose both spends are to the same address. getreceivedbyaddress would always count only one or the other spend at any given time, never both.
Using listtransactions, it would be very easy to count both. You see the first spend, you count it. You see the second spend, you count it. Total is double counted.
##### BitcoinTalk
#### Re: Version 0.3.18
##### 2010-12-09 14:37:05 UTC - [-](https://bitcointalk.org/index.php?topic=2162.msg28533#msg28533)
New transaction templates can be added as needed. Within a few days, there will be plenty of GPU power that accepts and works on it. Network support will be thorough long before there'll be enough clients who understand how to receive and interpret the new transaction.
Timestamp hashes are still already possible:
txin: 0.01
txout: 0.00 <appid, hash> OP_CHECKSIG
fee: 0.01
If there's an actual application like BitDNS getting ready to actually start inserting hashes, we can always add a specific transaction template for timestamps.
I like Hal Finney's idea for user-friendly timestamping. Convert the hash of a file to a bitcoin address and send 0.01 to it:
[Quote from: Hal on December 05, 2010, 11:43:56 PM](https://bitcointalk.org/index.php?topic=2077.msg27173#msg27173)
I thought of a simple way to implement the timestamp concept I mentioned above. Run sha1sum on the file you want to timestamp. Convert the result to a Bitcoin address, such as via [http://blockexplorer.com/q/hashtoaddress](http://blockexplorer.com/q/hashtoaddress) _. Then send a small payment to that address.
The money will be lost forever, as there is no way to spend it further, but the timestamp Bitcoin address will remain in the block chain as a record of the file's existence.
I understand that this is arguably not a good use of the Bitcoin distributed database, but nothing stops people from doing this so we should be aware that it may be done._
##### BitcoinTalk
#### Re: Version 0.3.18
##### 2010-12-09 15:17:53 UTC - [-](https://bitcointalk.org/index.php?topic=2162.msg28549#msg28549)
I came to agree with Gavin about whitelisting when I realized how quickly new transaction types can be added.
[Quote from: nanotube on December 09, 2010, 06:19:05 AM](https://bitcointalk.org/index.php?topic=2162.msg28434#msg28434)
why not make it easier on everyone and just allow say, 64 or 128 bytes of random data in a transaction?
That's already possible. <pubkey> OP_CHECKSIG. <pubkey> can be 33 to 120 bytes.
I also support a third transaction type for timestamp hash sized arbitrary data. There's no point not having one since you can already do it anyway. It would tell nodes they don't need to bother to index it.
##### BitcoinTalk
#### Re: JSON-RPC method idea: list transactions newer than a given txid
##### 2010-12-09 18:08:08 UTC - [-](https://bitcointalk.org/index.php?topic=2151.msg28640#msg28640)
[Quote from: jgarzik on December 09, 2010, 12:58:05 AM](https://bitcointalk.org/index.php?topic=2151.msg28330#msg28330)
I agree with you and satoshi about "txs after <txid>". My listtransactions (now xlisttransactions) patch pointedly does not have that feature, and never has.
As long as the interface is designed for things like showing the user the last N transactions history, it's fine, now that we have the Accounts feature making it easier to do payment detection the right way.
Gavin, could listtransactions have an option to list transactions for all accounts?
I'm not sure what the interface could be, maybe:
listtransactions <JSON null type> [count]
It would be hard to do that from the command line though.
I can't think of a good solution for the interface, that's the problem. Maybe "" special case like "" is. Everyone would have to make sure no user can create account name "".
[Quote from: jgarzik on December 09, 2010, 04:13:50 PM](https://bitcointalk.org/index.php?topic=2151.msg28572#msg28572)
Sure, and that's easy enough to track with transactions.
I don't get how that's "easy" to track with transactions.
##### BitcoinTalk
#### Re: Automated nightly builds
##### 2010-12-09 18:28:45 UTC - [-](https://bitcointalk.org/index.php?topic=644.msg28643#msg28643)
Thanks for setting this up Cdecker.
Is there any chance of getting it to build the GUI version also? If this is Ubuntu, if you get wxWidgets 2.9.0 it should just be a matter of following the steps in build-unix.txt exactly. Is this an environment where you can build wxWidgets once and leave it there and just keep using it?
##### BitcoinTalk
#### Re: BitDNS and Generalizing Bitcoin
##### 2010-12-09 21:02:42 UTC - [-](https://bitcointalk.org/index.php?topic=1790.msg28696#msg28696)
I think it would be possible for BitDNS to be a completely separate network and separate block chain, yet share CPU power with Bitcoin. The only overlap is to make it so miners can search for proof-of-work for both networks simultaneously.
The networks wouldn't need any coordination. Miners would subscribe to both networks in parallel. They would scan SHA such that if they get a hit, they potentially solve both at once. A solution may be for just one of the networks if one network has a lower difficulty.
I think an external miner could call getwork on both programs and combine the work. Maybe call Bitcoin, get work from it, hand it to BitDNS getwork to combine into a combined work.
Instead of fragmentation, networks share and augment each other's total CPU power. This would solve the problem that if there are multiple networks, they are a danger to each other if the available CPU power gangs up on one. Instead, all networks in the world would share combined CPU power, increasing the total strength. It would make it easier for small networks to get started by tapping into a ready base of miners.
##### BitcoinTalk
#### Re: BitDNS and Generalizing Bitcoin
##### 2010-12-09 22:46:50 UTC - [-](https://bitcointalk.org/index.php?topic=1790.msg28715#msg28715)
[Quote from: nanotube on December 09, 2010, 09:20:40 PM](https://bitcointalk.org/index.php?topic=1790.msg28700#msg28700)
seems that the miner would have to basically do "extra work". and if there's no reward from the bitdns mining from the extra work (which of course, slows down the main bitcoin work), what would be a miner's incentive to include bitdns (and whatever other side chains) ?
The incentive is to get the rewards from the extra side chains also for the same work.
While you are generating bitcoins, why not also get free domain names for the same work?
If you currently generate 50 BTC per week, now you could get 50 BTC and some domain names too.
You have one piece of work. If you solve it, it will solve a block from both Bitcoin and BitDNS. In concept, they're tied together by a Merkle Tree. To hand it in to Bitcoin, you break off the BitDNS branch, and to hand it in to BitDNS, you break off the Bitcoin branch.
In practice, to retrofit it for Bitcoin, the BitDNS side would have to have maybe ~200 extra bytes, but that's not a big deal. You've been talking about 50 domains per block, which would dwarf that little 200 bytes per block for backward compatibility. We could potentially schedule a far in future block when Bitcoin would upgrade to a modernised arrangement with the Merkle Tree on top, if we care enough about saving a few bytes.
Note that the chains are below this new Merkle Tree. That is, each of Bitcoin and BitDNS have their own chain links inside their blocks. This is inverted from the common timestamp server arrangement, where the chain is on top and then the Merkle Tree, because that creates one common master chain. This is two timestamp servers not sharing a chain.
##### BitcoinTalk
#### Re: Fees in BitDNS confusion
##### 2010-12-09 23:58:54 UTC - [-](https://bitcointalk.org/index.php?topic=2181.msg28729#msg28729)
Not locktime.
There's a possible design for far in the future:
You intentionally write a double-spend. You write it with the same inputs and outputs, but this time with a fee. When your double-spend gets into a block, the first spend becomes invalid. The payee does not really notice, because at the moment the new transaction becomes valid, the old one becomes invalid, and the new transaction simply takes its place.
It's easier said than implemented. There would be a fair amount of work to make a client that correctly writes the double-spend, manages the two versions in the wallet until one is chosen, handles all the corner cases. Every assumption in the existing code is that you're not trying to write double-spends.
There would need to be some changes on the Bitcoin Miner side also, to make the possibility to accept a double-spend into the transaction pool, but only strictly if the inputs and outputs match and the transaction fee is higher. Currently, double-spends are never accepted into the transaction pool, so every node bears witness to which transaction it saw first by working to put it into a block.
##### BitcoinTalk
#### Re: BitDNS and Generalizing Bitcoin
##### 2010-12-10 17:29:28 UTC - [-](https://bitcointalk.org/index.php?topic=1790.msg28917#msg28917)
Piling every proof-of-work quorum system in the world into one dataset doesn't scale.
Bitcoin and BitDNS can be used separately. Users shouldn't have to download all of both to use one or the other. BitDNS users may not want to download everything the next several unrelated networks decide to pile in either.
The networks need to have separate fates. BitDNS users might be completely liberal about adding any large data features since relatively few domain registrars are needed, while Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices.
Fears about securely buying domains with Bitcoins are a red herring. It's easy to trade Bitcoins for other non-repudiable commodities.
If you're still worried about it, it's cryptographically possible to make a risk free trade. The two parties would set up transactions on both sides such that when they both sign the transactions, the second signer's signature triggers the release of both. The second signer can't release one without releasing the other.
##### BitcoinTalk
#### Accounts example code
##### 2010-12-10 19:21:03 UTC - [-](https://bitcointalk.org/index.php?topic=2202.msg28947#msg28947)
Some sample pseudocode using the new Accounts based commands in 0.3.18.
print "send to " + getaccountaddress(username) + " to fund your account"
print "balance: " + getbalance(username, 0)
print "available balance: " + getbalance(username, 6)
// if you make a sale, move the money from their account to your "" account
if (move(username, "", amount, 6, "purchased item"))
SendTheGoods()
// withdrawal
sendfrom(username, bitcoinaddress, amount, 6, "withdrawal by user")
You can use listtransactions(username) to show them a list of their recent transactions.
##### BitcoinTalk
#### Re: BitDNS and Generalizing Bitcoin
##### 2010-12-10 19:55:12 UTC - [-](https://bitcointalk.org/index.php?topic=1790.msg28959#msg28959)
[Quote from: Hal on December 10, 2010, 07:14:04 PM](https://bitcointalk.org/index.php?topic=1790.msg28938#msg28938)
additional block chains would each create their own flavor of coins, which would trade with bitcoins on exchanges? These chain-specific coins would be used to reward miners on those chains, and to purchase some kinds of rights or privileges within the domain of that chain?
Right, the exchange rate between domains and bitcoins would float.
A longer interval than 10 minutes would be appropriate for BitDNS.
So far in this discussion there's already a lot of housekeeping data required. It will be much easier if you can freely use all the space you need without worrying about paying fees for expensive space in Bitcoin's chain. Some transactions:
Changing the IP record.
Name change. A domain object could entitle you to one domain, and you could change it at will to any name that isn't taken. This would encourage users to free up names they don't want anymore. Generated domains start out blank and the miner sells it to someone who changes it to what they want.
Renewal. Could be free, or maybe require consuming another domain object to renew. In that case, domain objects (domaincoins?) could represent the right to own a domain for a year. The spent fee goes to the miners in the next block fee.
##### BitcoinTalk
#### Re: BitDNS and Generalizing Bitcoin
##### 2010-12-10 20:19:39 UTC - [-](https://bitcointalk.org/index.php?topic=1790.msg28963#msg28963)
I agree. All transactions, IP changes, renewals, etc. should have some fee that goes to the miners.
You might consider a certain amount of work to generate a domain, instead of a fixed total circulation. The work per domain could be on a schedule that grows with Moore's Law. That way the number of domains would grow with demand and the number of people using it.
##### BitcoinTalk
#### Re: BitDNS and Generalizing Bitcoin
##### 2010-12-11 13:08:30 UTC - [-](https://bitcointalk.org/index.php?topic=1790.msg29159#msg29159)
@dtvan: all 3 excellent points.
1) IP records don't need to be in the chain, just do registrar function not DNS. And CA problem solved, neat.
2) Pick one TLD, .web +1.
3) Expiration and significant renewal costs, very important.
[Quote from: joe on December 11, 2010, 10:53:58 AM](https://bitcointalk.org/index.php?topic=1790.msg29130#msg29130)
However, thinking more about this now I support inclusion of additional coinbases / tracking systems in the main network. The reason for doing this is so as not to water down CPU power into multiple networks. We want one strong network, so the network should be versatile.
Avoiding CPU power fragmentation is no longer a reason. Independent networks/chains can share CPU power without sharing much else. See: [http://bitcointalk.org/index.php?topic=1790.msg28696#msg28696) and ">http://BitcoinTalk.org/index.php?topic=1790.msg28715#msg28715(http://bitcointalk.org/index.php?topic=1790.msg28715#msg28715)
##### BitcoinTalk
#### Re: Bitcoin and buffer overflow attacks
##### 2010-12-11 13:32:37 UTC - [-](https://bitcointalk.org/index.php?topic=2208.msg29165#msg29165)
[Quote from: da2ce7 on December 11, 2010, 05:49:22 AM](https://bitcointalk.org/index.php?topic=2208.msg29095#msg29095)
direct to IP address transfers seems like a obvious surface area to attack.
If you ever find anyone who turned it on. It's disabled by default.
[Quote from: witchspace on December 11, 2010, 09:59:40 AM](https://bitcointalk.org/index.php?topic=2208.msg29124#msg29124)
There is no way to be absolutely sure that there are no buffer overflow attacks. Although it would help to implement the client in a language that doesn't have buffer overflows because it checks array indices (Python, Java, C#, ...).
It's all STL. There are almost no buffers.
##### BitcoinTalk
#### Re: minimalistic bitcoin client on D language?
##### 2010-12-11 22:07:04 UTC - [-](https://bitcointalk.org/index.php?topic=2188.msg29259#msg29259)
[Quote from: Hal on December 11, 2010, 08:08:45 PM](https://bitcointalk.org/index.php?topic=2188.msg29223#msg29223)
I'd like to hear some specific criticisms of the code. To me it looks like an impressive job, although I'd wish for more comments. Now I've mostly studied the init, main, script and a bit of net modules. This is some powerful machinery.
That means a lot coming from you, Hal. Thanks.
##### BitcoinTalk
#### Re: PC World Article on Bitcoin
##### 2010-12-11 23:39:16 UTC - [-](https://bitcointalk.org/index.php?topic=2216.msg29280#msg29280)
It would have been nice to get this attention in any other context. WikiLeaks has kicked the hornet's nest, and the swarm is headed towards us.
##### BitcoinTalk
#### Added some DoS limits, removed safe mode (0.3.19)
##### 2010-12-12 18:22:33 UTC - [-](https://bitcointalk.org/index.php?topic=2228.msg29479#msg29479)
There's more work to do on DoS, but I'm doing a quick build of what I have so far in case it's needed, before venturing into more complex ideas. The build for this is version 0.3.19.
- Added some DoS controls
As Gavin and I have said clearly before, the software is not at all resistant to DoS attack. This is one improvement, but there are still more ways to attack than I can count.
I'm leaving the -limitfreerelay part as a switch for now and it's there if you need it.
- Removed "safe mode" alerts
"safe mode" alerts was a temporary measure after the 0.3.9 overflow bug. We can say all we want that users can just run with "-disablesafemode", but it's better just not to have it for the sake of appearances. It was never intended as a long term feature. Safe mode can still be triggered by seeing a longer (greater total PoW) invalid block chain.
Builds:
[http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.19/](http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.19/)
Martii Malmi (AKA Sirius) “COPA trial” email #249
Date: Mon, 13 Dec 2010 16:11:53 +0000
From: Satoshi Nakamoto <satoshin@gmx.com>
Subject: [bitcoin-list] Bitcoin 0.3.19 is released
To: bitcoin-list@lists.sourceforge.net
This is a minor release to add some DoS protection.
Changes:
- Added some DoS limits, though it's still far from DoS resistant.
- Removed "safe mode" alerts.
http://www.bitcoin.org/smf/index.php?topic=2228.0
Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.19/
bitcoin-list
[bitcoin-list] Bitcoin 0.3.19 is released
2010-12-13 16:12:09 UTC - [-](https://sourceforge.net/p/bitcoin/mailman/message/26744510/)
This is a minor release to add some DoS protection.
Changes:
- Added some DoS limits, though it's still far from DoS resistant.
- Removed "safe mode" alerts.
http://www.bitcoin.org/smf/index.php?topic=2228.0
Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.19/
Martii Malmi (AKA Sirius) “COPA trial” email #251
Date: Mon, 20 Dec 2010 18:10:06 +0000
From: Satoshi Nakamoto <satoshin@gmx.com>
Subject: Re: Bitcoin.org backups
To: Gavin Andresen <gavinandresen@gmail.com>
Cc: mmalmi@cc.hut.fi
Gavin Andresen wrote:
> On Mon, Dec 20, 2010 at 10:55 AM, <mmalmi@cc.hut.fi> wrote:
>> ShadowOfHarbringer described a way of mirroring the bitcoin.org website and
>> forum here:
>> http://www.bitcoin.org/smf/index.php?topic=2026.msg30043#msg30043
>>
>> Should we go by it and trust the database along with its password hashes to
>> some reliable community members who have servers?
>
> That seems like asking for trouble, and I think it would violate the
> implicit trust of everybody who's registered for the forums.
I agree, don't let the database out of your hands. There's private PM
in there, e-mail addresses, passwords.
BTW, password hashes = passwords. It's easy to break the hash of short
passwords people use on forums.
6 chars = 3 difficulty
7 chars = 410 difficulty
8 chars = 25418 difficulty
>> Another option is to
>> > encrypt the backups with pgp and store them in multiple places.
>
> That seems wiser. Daily backups copied ... somewhere ... seems like
> the right thing to do. If they're reasonably small (less than a
> gigabyte), I'd be happy to pay for Amazon S3 storage/bandwidth for
> them.
+1
Even with encryption, a trusted storage place is better.
Mike Hearn <mike@plan99.net>
Mon, Dec 27, 2010 at 8:21 PM
To: Satoshi Nakamoto <satoshin@gmx.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?_
Satoshi Nakamoto <satoshin@gmx.com>
Wed, Dec 29, 2010 at 10:42 PM
To: Mike Hearn <mike@plan99.net>
_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)._
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.
Here's some more about it:
"Here's my client-mode implementation so far. Client-only mode only records block headers and doesn't use the tx index. It can't generate, but it can still send and receive transactions. It's not fully finished for use by end-users, but it doesn't matter because it's a complete no-op if fClient is not enabled. At this point it's mainly documentation showing the cut-lines for client-only re-implementers.
With fClient=true, I've only tested the header-only initial download.
A little background. CBlockIndex contains all the information of the block header, so to operate with headers only, I just maintain the CBlockIndex structure as usual. The nFile/nBlockPos are null, since the full block is not recorded on disk.
The code to gracefully switch between client-mode on/off without deleting blk*.dat in between is not implemented yet. It would mostly be a matter of having non-client LoadBlockIndex ignore block index entries with null block pos. That would make it re-download those as full blocks. Switching back to client-mode is no problem, it doesn't mind if the full blocks are there.
If the initial block download becomes too long, we'll want client mode as an option so new users can get running quickly. With graceful switch-off of client mode, they can later turn off client mode and have it download the full blocks if they want to start generating. They should rather just use a getwork miner to join a pool instead.
Client-only re-implementations would not need to implement EvalScript at all, or at most just implement the five ops used by the standard transaction templates."
_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._
Educated guess, and the maths work out to round numbers. I wanted something that would be not too low if it was very popular and not too high if it wasn't.
_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._
If propagation is 1 minute, then 10 minutes was a good guess. Then nodes are only losing 10% of their work (1 minute/10 minutes). If the CPU time wasted by latency was a more significant share, there may be weaknesses I haven't thought of. An attacker would not be affected by latency, since he's chaining his own blocks, so he would have an advantage. The chain would temporarily fork more often due to latency.
_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?_
A higher limit can be phased in once we have actual use closer to the limit and make sure it's working OK.
Eventually when we have client-only implementations, the block chain size won't matter much. Until then, while all users still have to download the entire block chain to start, it's nice if we can keep it down to a reasonable size.
With very high transaction volume, network nodes would consolidate and there would be more pooled mining and GPU farms, and users would run client-only. With dev work on optimising and parallelising, it can keep scaling up.
Whatever the current capacity of the software is, it automatically grows at the rate of Moore's Law, about 60% per year.
diff -u old\db.cpp new\db.cpp
--- old\db.cpp Sat Dec 18 18:35:59 2010
+++ new\db.cpp Sun Dec 19 20:53:59 2010
@@ -464,29 +464,32 @@
ReadBestInvalidWork(bnBestInvalidWork);
// Verify blocks in the best chain
- CBlockIndex* pindexFork = NULL;
- for (CBlockIndex* pindex = pindexBest; pindex && pindex->pprev; pindex = pindex->pprev)
+ if (!fClient)
{
- if (pindex->nHeight < nBestHeight-2500 && !mapArgs.count("-checkblocks"))
- break;
- CBlock block;
- if (!block.ReadFromDisk(pindex))
- return error("LoadBlockIndex() : block.ReadFromDisk failed");
- if (!block.CheckBlock())
+ CBlockIndex* pindexFork = NULL;
+ for (CBlockIndex* pindex = pindexBest; pindex && pindex->pprev; pindex = pindex->pprev)
{
- printf("LoadBlockIndex() : * found bad block at %d, hash=%s\n", pindex->nHeight, pindex->GetBlockHash().ToString().c_str());
- pindexFork = pindex->pprev;
+ if (pindex->nHeight < nBestHeight-2500 && !mapArgs.count("-checkblocks"))
+ break;
+ CBlock block;
+ if (!block.ReadFromDisk(pindex))
+ return error("LoadBlockIndex() : block.ReadFromDisk failed");
+ if (!block.CheckBlock())
+ {
+ printf("LoadBlockIndex() : * found bad block at %d, hash=%s\n", pindex->nHeight, pindex->GetBlockHash().ToString().c_str());
+ pindexFork = pindex->pprev;
+ }
+ }
+ if (pindexFork)
+ {
+ // Reorg back to the fork
+ printf("LoadBlockIndex() : * moving best chain pointer back to block %d\n", pindexFork->nHeight);
+ CBlock block;
+ if (!block.ReadFromDisk(pindexFork))
+ return error("LoadBlockIndex() : block.ReadFromDisk failed");
+ CTxDB txdb;
+ block.SetBestChain(txdb, pindexFork);
}
- }
- if (pindexFork)
- {
- // Reorg back to the fork
- printf("LoadBlockIndex() : * moving best chain pointer back to block %d\n", pindexFork->nHeight);
- CBlock block;
- if (!block.ReadFromDisk(pindexFork))
- return error("LoadBlockIndex() : block.ReadFromDisk failed");
- CTxDB txdb;
- block.SetBestChain(txdb, pindexFork);
}
return true;
diff -u old\main.cpp new\main.cpp
--- old\main.cpp Sat Dec 18 18:35:59 2010
+++ new\main.cpp Sun Dec 19 20:53:59 2010
@@ -637,6 +637,9 @@
if (!IsStandard())
return error("AcceptToMemoryPool() : nonstandard transaction type");
+ if (fClient)
+ return true;
+
// Do we already have it?
uint256 hash = GetHash();
CRITICALBLOCK(csmapTransactions)
@@ -1308,23 +1311,26 @@
if (!CheckBlock())
return false;
- //// issue here: it doesn't know the version
- unsigned int nTxPos = pindex->nBlockPos + ::GetSerializeSize(CBlock(), SER_DISK) - 1 + GetSizeOfCompactSize(vtx.size());
-
- map<uint256, CTxIndex> mapUnused;
- int64 nFees = 0;
- foreach(CTransaction& tx, vtx)
+ if (!fClient)
{
- CDiskTxPos posThisTx(pindex->nFile, pindex->nBlockPos, nTxPos);
- nTxPos += ::GetSerializeSize(tx, SER_DISK);
+ //// issue here: it doesn't know the version
+ unsigned int nTxPos = pindex->nBlockPos + ::GetSerializeSize(CBlock(), SER_DISK) - 1 + GetSizeOfCompactSize(vtx.size());
+
+ map<uint256, CTxIndex> mapUnused;
+ int64 nFees = 0;
+ foreach(CTransaction& tx, vtx)
+ {
+ CDiskTxPos posThisTx(pindex->nFile, pindex->nBlockPos, nTxPos);
+ nTxPos += ::GetSerializeSize(tx, SER_DISK);
- if (!tx.ConnectInputs(txdb, mapUnused, posThisTx, pindex, nFees, true, false))
+ if (!tx.ConnectInputs(txdb, mapUnused, posThisTx, pindex, nFees, true, false))
+ return false;
+ }
+
+ if (vtx[0].GetValueOut() > GetBlockValue(pindex->nHeight, nFees))
return false;
}
- if (vtx[0].GetValueOut() > GetBlockValue(pindex->nHeight, nFees))
- return false;
-
// Update block index on disk without changing it in memory.
// The memory index structure will be changed after the db commits.
if (pindex->pprev)
@@ -1378,7 +1384,7 @@
foreach(CBlockIndex* pindex, vDisconnect)
{
CBlock block;
- if (!block.ReadFromDisk(pindex))
+ if (!block.ReadFromDisk(pindex, !fClient))
return error("Reorganize() : ReadFromDisk for disconnect failed");
if (!block.DisconnectBlock(txdb, pindex))
return error("Reorganize() : DisconnectBlock failed");
@@ -1395,7 +1401,7 @@
{
CBlockIndex* pindex = vConnect[i];
CBlock block;
- if (!block.ReadFromDisk(pindex))
+ if (!block.ReadFromDisk(pindex, !fClient))
return error("Reorganize() : ReadFromDisk for connect failed");
if (!block.ConnectBlock(txdb, pindex))
{
@@ -1526,7 +1532,7 @@
txdb.Close();
- if (pindexNew == pindexBest)
+ if (!fClient && pindexNew == pindexBest)
{
// Notify UI to display prev block's coinbase if it was ours
static uint256 hashPrevBestCoinBase;
@@ -1547,10 +1553,6 @@
// These are checks that are independent of context
// that can be verified before saving an orphan block.
- // Size limits
- if (vtx.empty() || vtx.size() > MAXBLOCKSIZE || ::GetSerializeSize(*this, SERNETWORK) > MAXBLOCK_SIZE)
- return error("CheckBlock() : size limits failed");
-
// Check proof of work matches claimed amount
if (!CheckProofOfWork(GetHash(), nBits))
return error("CheckBlock() : proof of work failed");
@@ -1559,6 +1561,13 @@
if (GetBlockTime() > GetAdjustedTime() + 2 * 60 * 60)
return error("CheckBlock() : block timestamp too far in the future");
+ if (fClient && vtx.empty())
+ return true;
+
+ // Size limits
+ if (vtx.empty() || vtx.size() > MAXBLOCKSIZE || ::GetSerializeSize(*this, SERNETWORK) > MAXBLOCK_SIZE)
+ return error("CheckBlock() : size limits failed");
+
// First transaction must be coinbase, the rest must not be
if (vtx.empty() || !vtx[0].IsCoinBase())
return error("CheckBlock() : first tx is not coinbase");
@@ -1623,13 +1632,14 @@
return error("AcceptBlock() : out of disk space");
unsigned int nFile = -1;
unsigned int nBlockPos = 0;
- if (!WriteToDisk(nFile, nBlockPos))
- return error("AcceptBlock() : WriteToDisk failed");
+ if (!fClient)
+ if (!WriteToDisk(nFile, nBlockPos))
+ return error("AcceptBlock() : WriteToDisk failed");
if (!AddToBlockIndex(nFile, nBlockPos))
return error("AcceptBlock() : AddToBlockIndex failed");
// Relay inventory, but don't relay old inventory during initial block download
- if (hashBestChain == hash)
+ if (!fClient && hashBestChain == hash)
CRITICALBLOCK(csvNodes)
foreach(CNode* pnode, vNodes)
if (nBestHeight > (pnode->nStartingHeight != -1 ? pnode->nStartingHeight - 2000 : 55000))
@@ -2405,6 +2415,8 @@
{
if (fShutdown)
return true;
+ if (fClient && inv.type == MSG_TX)
+ continue;
pfrom->AddInventoryKnown(inv);
bool fAlreadyHave = AlreadyHave(txdb, inv);
@@ -2441,6 +2453,9 @@
if (inv.type == MSG_BLOCK)
{
+ if (fClient)
+ return true;
+
// Send block from disk
map<uint256, CBlockIndex*>::iterator mi = mapBlockIndex.find(inv.hash);
if (mi != mapBlockIndex.end())
@@ -2486,6 +2501,8 @@
else if (strCommand == "getblocks")
{
+ if (fClient)
+ return true;
CBlockLocator locator;
uint256 hashStop;
vRecv >> locator >> hashStop;
@@ -2556,6 +2573,8 @@
else if (strCommand == "tx")
{
+ if (fClient)
+ return true;
vector<uint256> vWorkQueue;
CDataStream vMsg(vRecv);
CTransaction tx;
@@ -2620,6 +2639,33 @@
if (ProcessBlock(pfrom, &block))
mapAlreadyAskedFor.erase(inv);
+ }
+
+
+ else if (strCommand == "headers")
+ {
+ if (!fClient)
+ return true;
+ vector<CBlock> vHeaders;
+ vRecv >> vHeaders;
+
+ uint256 hashBestBefore = hashBestChain;
+ foreach(CBlock& block, vHeaders)
+ {
+ block.vtx.clear();
+
+ printf("received header %s\n", block.GetHash().ToString().substr(0,20).c_str());
+
+ CInv inv(MSG_BLOCK, block.GetHash());
+ pfrom->AddInventoryKnown(inv);
+
+ if (ProcessBlock(pfrom, &block))
+ mapAlreadyAskedFor.erase(inv);
+ }
+
+ // Request next batch
+ if (hashBestChain != hashBestBefore)
+ pfrom->PushGetBlocks(pindexBest, uint256(0));
}
diff -u old\main.h new\main.h
--- old\main.h Sat Dec 18 18:35:59 2010
+++ new\main.h Sun Dec 19 20:53:59 2010
@@ -619,6 +619,8 @@
bool ReadFromDisk(CDiskTxPos pos, FILE** pfileRet=NULL)
{
+ assert(!fClient);
+
CAutoFile filein = OpenBlockFile(pos.nFile, 0, pfileRet ? "rb+" : "rb");
if (!filein)
return error("CTransaction::ReadFromDisk() : OpenBlockFile failed");
@@ -1174,6 +1176,7 @@
bool ReadFromDisk(unsigned int nFile, unsigned int nBlockPos, bool fReadTransactions=true)
{
+ assert(!fClient);
SetNull();
// Open history file to read
@@ -1231,7 +1234,7 @@
//
-// The block chain is a tree shaped structure starting with the
+// The block index is a tree shaped structure starting with the
// genesis block at the root, with each block potentially having multiple
// candidates to be the next block. pprev and pnext link a path through the
// main/longest chain. A blockindex may have multiple pprev pointing back
diff -u old\net.cpp new\net.cpp
--- old\net.cpp Wed Dec 15 22:33:09 2010
+++ new\net.cpp Sun Dec 19 21:51:27 2010
@@ -51,7 +51,15 @@
pindexLastGetBlocksBegin = pindexBegin;
hashLastGetBlocksEnd = hashEnd;
- PushMessage("getblocks", CBlockLocator(pindexBegin), hashEnd);
+ /// Client todo: After the initial block header download, start using getblocks
+ /// here instead of getheaders. For blocks generated after the first time the
+ /// program was run, we need to download full blocks to watch for received
+ /// transactions in them. We're able to download headers only for blocks
+ /// generated before we ever ran because they can't contain txes for us.
+ if (::fClient)
+ PushMessage("getheaders", CBlockLocator(pindexBegin), hashEnd);
+ else
+ PushMessage("getblocks", CBlockLocator(pindexBegin), hashEnd);
}
[](https://plan99.net/~mike/satoshi-emails/thread3.html?ui=2&ik=ee2dd21bb5&view=att&th=12d34154f69f6dc7&attid=0.1&disp=inline&safe=1&zw)
client-mode.patch
11K
Mike Hearn <mike@plan99.net>
Thu, Dec 30, 2010 at 12:27 AM
To: Satoshi Nakamoto <satoshin@gmx.com>
_Thanks for the info.
I reached the same conclusions about client only nodes and this is
what I've been implementing. I'm nearly there ..... I have block chain
download, parsing and verification of the blocks/transactions done,
with creation of spend transactions almost done.
v1 will basically do as you propose, with the possible optimization of
storing only the blocks needed to form the block locator (with the
exponential thinning). As Android provides local storage that is
private to the app, you don't need to store the entire block chain to
be able to accept new blocks ... just enough to ensure you can always
stay on the longest chain.
By the way, your code is easy to read and has been an invaluable
reference. So thanks for that.
In v2 I'm thinking of showing transactions before they are integrated
into the block chain by running secure/locked down relay nodes that
send messages to the phones when a transaction is accepted into the
memory pool. Android provides a secure, low power back channel to
every phone. Messages are stored server side if the device is offline
and apps are automatically started on the phone to handle incoming
messages.
So as long as the relay nodes are unhacked, this system should give
enough trust that low value transactions can be shown in the UI
immediately. It introduces some centralization/single points of
failure, but if the relay mechanism dies or is hacked, the damage only
lasts for 10 minutes until the new blocks are downloaded.
> Client-only re-implementations would not need to implement EvalScript at
> all, or at most just implement the five ops used by the standard transaction
> templates."
__Indeed, there's no point in client-only implementations implementing
EvalScript because they can't verify transactions aren't being double
spent without storing and indexing the entire block chain. My code
parses the scripts and then relies on them having a standard
structure, but doesn't actually run them.
_> Educated guess, and the maths work out to round numbers. I wanted something
> that would be not too low if it was very popular and not too high if it
> wasn't._It'd be interesting to see the working for this. In some sense the
number of coins is arbitrary as the nanocoin representation means the
issuance is so huge it's practically infinite.
_> A higher limit can be phased in once we have actual use closer to the limit
> and make sure it's working OK._It'd be worth implementing some kind of more robust auto update
mechanism, or a schedule for the phase in of this, if only because
when people evaluate "is BitCoin worth my time and effort" a solid
plan for scaling up is good to have written down.
I'm not worried about the physical capabilities of the hardware, but
more protocol ossification as the app is reimplemented and nodes which
don't auto-update themselves increase in number. Client only
reimplementations pose no problems of course, but other systems like
SMTP have proven impossible to globally upgrade despite having
extension mechanisms built in .... just too many implementations and
too many installations._
Martii Malmi (AKA Sirius) “COPA trial” email #254
Date: Thu, 06 Jan 2011 18:31:26 +0000
From: Satoshi Nakamoto <satoshin@gmx.com>
Subject: Re: Writing about BitCoin
To: Gavin Andresen <gavinandresen@gmail.com>
Cc: Martti Malmi <mmalmi@cc.hut.fi>
Gavin Andresen wrote:
> I'd be happy to talk to Rainey;
Great
> Satoshi, I assume you don't want to
> deal with press/PR/interviews ?
True
> We could decline to talk to the press-- Satoshi, I know you've
> expressed concern about bitcoin growing too big too fast, and being
> unable to keep up with traffic/attacks/feature requests/etc. But I
> don't think ignoring the press will make them go away; they'll just
> talk to somebody else. I think it is better to give a realistic
> impression of bitcoin (it is cutting-edge, beta software that is still
> being developed, it is not poised to replace PayPal or the Euro
> anytime soon, etc) rather than let somebody over-enthusiastic become
> "the unofficial bitcoin spokesperson."
You're the best person to do it.
EFF is really important. We want to have a good relationship with them.
We're the type of project they like; they've helped the TOR project
and done a lot to protect P2P file sharing.