#

msg28729

(4 articles)

Kicking the Hornet's Nest - part 22 - the end

# Kicking the Hornet's Nest - third edition - part 22 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 506 - 527 (the end) ---- **Satoshi Nakamoto** <satoshin@gmx.com> Fri, Jan 7, 2011 at 1:00 PM To: Mike Hearn <mike@plan99.net> _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._ That's great! The first client-only implementation will really start to move things to the next step. Is it going to be open source, or Google proprietary? **Mike Hearn** <mike@plan99.net> Fri, Jan 7, 2011 at 1:24 PM To: Satoshi Nakamoto <satoshin@gmx.com> > That's great! The first client-only implementation will really start to > move things to the next step. Is it going to be open source, or Google > proprietary? _Open source. It has to be - I am developing it as a personal project in my spare time and Googles policy is that this is only allowed if you open source the results. But I would have done that anyway. I managed to spend my first coins on the testnet with my app a few days ago, hopefully will get another chance to make progress this weekend. Probably will have something to show publically sometime in Feb, touch wood._ **Satoshi Nakamoto** <satoshin@gmx.com> Mon, Jan 10, 2011 at 4:34 PM To: Mike Hearn <mike@plan99.net> Open source. Perfect. Once your code shows how to simplify it down, other authors can follow your lead. Client is a less daunting challenge than full implementation. If it's within reach of more developers, they'll come up with more polished UI and other things I didn't think of. I expect the original software will become the industrial old thing used by GPU farms and pool servers. BTW, later a good feature for a client version is to keep your private keys encrypted and you give your password each time you send. _I managed to spend my first coins on the testnet with my app a few days ago, hopefully will get another chance to make progress this weekend. Probably will have something to show publically sometime in Feb, touch wood._ Great, keep me updated. _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._ It works out to an even 10 minutes per block: 21000000 / (50 BTC * 24hrs * 365days * 4years * 2) = 5.99 blocks/hour I fudged it to 364.58333 days/year. The halving of 50 BTC to 25 BTC is after 210000 blocks or around 3.9954 years, which is approximate anyway based on the retargeting mechanism's best effort. I thought about 100 BTC and 42 million, but 42 million seemed high. I wanted typical amounts to be in a familiar range. If you're tossing around 100000 units, it doesn't feel scarce. The brain is better able to work with numbers from 0.01 to 1000. If it gets really big, the decimal can move two places and cents become the new coins. **Mike Hearn** <mike@plan99.net> Mon, Jan 10, 2011 at 4:48 PM To: Satoshi Nakamoto <satoshin@gmx.com> _Ah, of course, that makes sense._ _By the way, if you didn't see it already, there's a discussion on the security of secp256k1 on the forum:_ [_http://www.bitcoin.org/smf/index.php?topic=2699.0_](http://www.bitcoin.org/smf/index.php?topic=2699.0) _Hal (i presume this is Hal Finney) seems to think the curve is at higher risk of attack than random curves. I guess you chose secp256k1 for the mentioned performance improvement?_ _[Quoted text hidden]_ **Satoshi Nakamoto** <satoshin@gmx.com> Mon, Jan 10, 2011 at 8:47 PM To: Mike Hearn <mike@plan99.net> _By the way, if you didn't see it already, there's a discussion on the security of secp256k1 on the forum: _[_http://www.bitcoin.org/smf/index.php?topic=2699.0_](http://www.bitcoin.org/smf/index.php?topic=2699.0)_ Hal (i presume this is Hal Finney)_ Yes, it's him. He was supportive on the Cryptography list and ran one of the first nodes. _seems to think the curve is at higher risk of attack than random curves. I guess you chose secp256k1 for the mentioned performance improvement?_ I must admit, this project was 2 years of development before release, and I could only spend so much time on each of the many issues. I found guidance on the recommended size for SHA and RSA, but nothing on ECDSA which was relatively new. I took the recommended key size for RSA and converted to equivalent key size for ECDSA, but then increased it so the whole app could be said to be 256-bit security. I didn't find anything to recommend a curve type so I just... picked one. Hopefully there is enough key size to make up for any deficiency. At the time, I was concerned whether the bandwidth and storage sizes would be practical even with ECDSA. RSA's huge keys were out of the question. Storage and bandwidth seemed tighter back then. I felt the size was either only just becoming practical, or would be soon. When I presented it, I was surprised nobody else was concerned about size, though I was also surprised how many issues they argued, and more surprised that every single one was something I had thought of and solved. As it turns out, ECDSA verification time may be the greater bottleneck. (In my tests, OpenSSL was taking 3.5ms per ECDSA verify, or about 285 verifies per second) Client versions bypass the problem. As things have evolved, the number of people who need to run full nodes is less than I originally imagined. The network would be fine with a small number of nodes if processing load becomes heavy. **Martii Malmi (AKA Sirius) “COPA trial” email #256** **Date: Tue, 25 Jan 2011 18:34:03 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Fwd: Bitcoin question** **To: mmalmi@cc.hut.fi** The paper was published in 2008. Someone needs to correct Wikipedia; it incorrectly says the paper was published in 2009. The paper was released earlier than the software. _mmalmi@cc.hut.fi wrote:_ _> Can you comment on this?_ _>_ _> ----- Forwarded message from cjwells_1@yahoo.com -----_ _> Date: Mon, 24 Jan 2011 00:32:48 -0800 (PST)_ _> From: "Constance J. Wells" <cjwells_1@yahoo.com>_ _> Reply-To: "Constance J. Wells" <cjwells_1@yahoo.com>_ _> Subject: Re:_ _> To: mmalmi@cc.hut.fi_ _>_ _> Martti,_ _> Thank you for the pdf. It looks great. I do not see a date on it. When_ _> was it written?_ _>_ _> Mr. Mark Herpel of Digital Gold Currency Magazine brought Bitcoin to my_ _> attention for inclusion in my thesis. The thesis working title is:_ _> Digital Currency Systems: Emerging B2B e-Commerce Alternative During_ _> Monetary Crisis in the United States. I discuss the five types of_ _> systems per Mr. Herpels suggestion._ _>_ _> Appreciate it and hope to talk soon._ _>_ _> C._ _>_ _> Constance J. Wells, CeM, PMP: PMI certified_ _> Denver, CO U.S.A._ _> 303-730-6609_ _>_ _> --- On Mon, 1/24/11, mmalmi@cc.hut.fi <mmalmi@cc.hut.fi> wrote:_ _>_ _> From: mmalmi@cc.hut.fi <mmalmi@cc.hut.fi>_ _> Subject: Re:_ _> To: "Constance J. Wells" <cjwells_1@yahoo.com>_ _> Date: Monday, January 24, 2011, 1:22 AM_ _>_ _> Hi Constance,_ _>_ _> Thanks for your interest in Bitcoin, feel free to cite. There's also_ _> Satoshi Nakamoto's paper available at http://www.bitcoin.org/bitcoin.pdf_ _> if you want something with a more formal touch. Please let us know when_ _> your thesis is finished!_ _>_ _>_ _> -Martti_ _>_ _>> Martti Malmi_ _>> Currently I am a full time student at-_ _>> http://info.aspen.edu/_ _>> Aspen University, in Denver, CO, 303-333-4224._ _>> Masters of Science in Technology and Innovation._ _>>_ _>> I am writing my Thesis under the subject heading, digital currency_ _>> systems. May I cite your site in my Thesis?_ _>>_ _>> Thank you._ _>> Constance_ _>> Constance J. Wells, CeM, PMP: PMI certified_ _>> Denver, CO U.S.A._ _>> 303-730-6609_ _>>_ **Martii Malmi (AKA Sirius) “COPA trial” email #260** **Date: Tue, 22 Feb 2011 19:49:19 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: 0.3.20 release : shipped** **To: Gavin Andresen <gavinandresen@gmail.com>, Martti Malmi <mmalmi@cc.hut.fi>** _> I have not sent a message to the sourceforge bitcoin-list mailing list_ _> because I don't think I have permission; Satoshi, can you give me_ _> permission, encrypt the mailman password with my public key and send_ _> it to me, or just post the announcement?_ Martti should give you the Drupal admin password. Any subscriber can post to bitcoin-list. Here's the admin password in case you need it later. Gavin: -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.7 (MingW32) - WinPT 1.2.0 hQIOAxfAPINgyySWEAf9GHyuMqxkhoBe96hbHoFPIR4ORpMS/v2mpCT70UmgTt46 GVO5MeEOFE4JUqltYUaAE2u7e7+BbyNFeNk4o0kwJIWUXbRoBHj59vx+yzmeRLd9 YxTWxZA2zOVcYcYoDkiYAatwlQWQefzwYFcCnBSSsY1F9XLHMtLqNadhftOregoE 5Prhjk4ScAEOAmJ2CfYvWLD6FPAe4s6nXzP656oQghMgUivYoowHAjGUSvd8f1Qb fkV0isGIYCpHCOSZDZpysPCm63ibEeiuylvkT7Ayj2HoonqypFdv05mtyS7Jtq6a s06UqjLSyICoGJVk4x5HZhusgmbqViLvb6gM+iadbQf/U9KEKA5KyF0JvjYlx97k Bm7WpBIxKnP6Migl/Otol85EYt9rWN0lozLGw5Ko1JTZzXv3RrTsJafUYnDyAvtR 20JExoG84LatTeFiTqVWHiWZbYG2ECJHTO6jOmITvNvq/OgCID4hQvjvNQiXghae qzolzmZVEwDGAybWJoSvAsXjDWbAyHt9WJztHPgVRxgTBrnhoLAX0FwKGTCr7L/t emVEUqgEf3WqmljD+cCXSNVloQxGmPvaSsbITIZvX/emwq4MAC+SuRmJLJp6kSmu UhkxZMipvYHfyBPXoonAM7oYXNIaFQryS66UlEziSUevvU8TXiZMeUyyiMirOBXC itKhAedpc7NQYG+/KohTS0U9QfdygBfE2o6M96tRKFdMmbQz3Gyq0BaBpp98+ve+ VOVp90mYv9zq43G7tHnZektEjGzplHj0HzWhfbiy2dBrDGhkByYN4G6kX0JvU4ZX /ixmbOf5qZPqcgmz7fYDxKnkUQVumoEIfNXrUlAPcI2Ql9TnY0NIg9ZIVOGeT4lE 80kYloQVdCdnrJ7yLWexO0W1kSs= =S7eV -----END PGP MESSAGE----- Martti: -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.7 (MingW32) - WinPT 1.2.0 hQEMA+kEt/4bukJEAQgAlt5/Ks5pZPeusK0yefyMn7BqIVcOVHDaXbnf4dLKqq5J 6bKyMlkyYjhm1itZabi+IaV9k+1r7Wo50qOqfZNCSmG63hX3asXWd7QxThj4KDxr fvuUfiduf2AyZcB4r/baw1hsdC3VGxQutU0ookuJqfvCIse77clS2WimKJ5hrh5G KVdGApk3TxbILknalIs3mUw81sL0nvbO/aNrHiiNj44YU3Ehf5CieEJInHeYGTsJ AABLZcH6B7nymA8D4nrAAnDcjcSE8+iWMOtzI2duCHKtA+LVJOsg8n/zHqK9SZNF w+Xud7mBi/ZvnFGwCZh7cqJ/jZhNLLTQHiLr8M+i7dKhAekFho8aarOV9V4Cp2hT a8bQdbgwsednyjCzaq+C8xU+aYJcAV95qK6QG2hlT8xpDU2KHBHWIjDmPKlzgvKb 8/dQo5VDvtQkdyvrd9pMJeOUxFKEVW5ph+4LzKjKEWE1kJhzAwbxQMNKkXLzZJIa hJMNAVHDjnYcuI8EgJT+TjH2Kx+KwHX/OEOFaDXGP7XwMOuVZTVtbXnsJ24SFa1i m4U= =0TBL -----END PGP MESSAGE----- **Open sourced my Java SPV impl** 10 messages **Mike Hearn** <mike@plan99.net> Mon, Mar 7, 2011 at 2:13 PM To: Satoshi Nakamoto <satoshin@gmx.com> _Hi Satoshi, I hope you are doing well. I finally got all the lawyers happy enough to release BitCoinJ under the Google name using the Apache 2 license: _[_http://www.bitcoin.org/smf/index.php?topic=4236.0_](http://www.bitcoin.org/smf/index.php?topic=4236.0)_ It's incomplete - notably it doesn't properly handle block chain splits yet - but the rest is coming. I put a lot of work into documentation and comments so hopefully it'll open up BitCoin to a new audience who weren't able to understand/build the current code. Over the next month or two I'll be finishing off some of the bigger missing pieces for a full client-mode implementation. I know you are busy right now but I'm hoping you can find time to answer a few questions I had. As part of doing full SPV I'm thinking of adding a getmerklebranch message to the protocol. This would return a set of {blockhash, branch} pairs given tx hashes, so allowing verification of a broadcast transaction before it was incorporated into a block without storing the full chain. Does that approach sound good to you? Also, I've been thinking of exploring different transaction types lately, eg by removing the IsStandard() checks for the testnet. It's clear you put a lot of thought into transactions beyond simply moving coins around up front, but unfortunately none of it was in the paper or documented in the code. Escrow, multi-pay and so on are all interesting but I was wondering if you could compile a list of ideas for things we can do with the scripting language at some point. Finally, the code that allows for transaction replacement has been disabled but the comment doesn't say why. Is this just to reduce the attack surface/complexity or is there a deeper reason? I haven't fully understood why sequence numbers are a property of the tx inputs rather than the tx itself. Hope you can find the time/energy to rejoin us soon! I don't know if you've seen this: _[_http://bitcoin.sipa.be/speed-lin.png_](http://bitcoin.sipa.be/speed-lin.png)_ but it's exciting times for the network! thanks! __/mike_ **Satoshi Nakamoto** <satoshin@gmx.com> Wed, Mar 9, 2011 at 5:15 PM To: Mike Hearn <mike@plan99.net> _I hope you are doing well. I finally got all the lawyers happy enough to release BitCoinJ under the Google name using the Apache 2 license: It's incomplete - notably it doesn't properly handle block chain splits yet - but the rest is coming. I put a lot of work into documentation and comments so hopefully it'll open up BitCoin to a new audience who weren't able to understand/build the current code. Over the next month or two I'll be finishing off some of the bigger missing pieces for a full client-mode implementation._ That's great news! Much complexity can be left behind in a clean rewrite with only client requirements, and it opens it to Java developers too. _I know you are busy right now but I'm hoping you can find time to answer a few questions I had._ I'm happy to answer any questions. _As part of doing full SPV I'm thinking of adding a getmerklebranch message to the protocol. This would return a set of {blockhash, branch} pairs_ That's a CMerkleTx _given tx hashes, so allowing verification of a broadcast transaction before it was incorporated into a block without storing the full chain. Does that approach sound good to you?_ I don't understand. A merkle branch links a tx back to a block, which only has significance if the block exhibits proof-of-work. Linking back to an as-yet unsolved block proves nothing. Network nodes are able to verify 0-conf txes because they have the complete tx index, so they can: 1) verify signatures against dependencies. 2) say that they haven't seen another spend yet, because they know about every tx in existence. Are you talking about CMerkleTxes for the tx's dependencies? That would get part 1), but not part 2). If you don't know about all txes in existence, I don't know how to do 2). You could only rely on trusting other nodes for that. That trust can be distributed over multiple nodes. Nodes only relay transactions they accept as valid. If you receive inv messages for a tx from all the nodes you're connected to, they're attesting that it's valid and the first spend they saw. _Also, I've been thinking of exploring different transaction types lately, eg by removing the IsStandard() checks for the testnet._ Very good idea. That should definitely be allowed on -testnet. _It's clear you put a lot of thought into transactions beyond simply moving coins around up front, but unfortunately none of it was in the paper or documented in the code. Escrow, multi-pay and so on are all interesting but I was wondering if you could compile a list of ideas for things we can do with the scripting language at some point. Finally, the code that allows for transaction replacement has been disabled but the comment doesn't say why. Is this just to reduce the attack surface/complexity or is there a deeper reason?_ Just to reduce surface area. It wouldn't help with increasing tx fee. A tx starts being valid at nLockTime. It wouldn't work to have a tx that stops being valid at a certain time; once a tx ever becomes valid, it must stay valid permanently. See these threads: [http://www.bitcoin.org/smf/index.php?topic=1786.msg22119#msg22119](/home/crrdlx/Dropbox/My%20Docs/books/kicking%20hornets%20nest%20-%20complete%20writings%20of%20satoshi%20nakamoto/edition3_files/_blank) [http://www.bitcoin.org/smf/index.php?topic=2181.msg28729#msg28729](/home/crrdlx/Dropbox/My%20Docs/books/kicking%20hornets%20nest%20-%20complete%20writings%20of%20satoshi%20nakamoto/edition3_files/_blank) _I haven't fully understood why sequence numbers are a property of the tx inputs rather than the tx itself._ It's for contracts. An unrecorded open transaction can keep being replaced until nLockTime. It may contain payments by multiple parties. Each input owner signs their input. For a new version to be written, each must sign a higher sequence number (see IsNewerThan). By signing, an input owner says "I agree to put my money in, if everyone puts their money in and the outputs are this." There are other options in SignatureHash such as SIGHASH_SINGLE which means "I agree, as long as this one output (i.e. mine) is what I want, I don't care what you do with the other outputs.". If that's written with a high nSequenceNumber, the party can bow out of the negotiation except for that one stipulation, or sign SIGHASH_NONE and bow out completely. The parties could create a pre-agreed default option by creating a higher nSequenceNumber tx using OP_CHECKMULTISIG that requires a subset of parties to sign to complete the signature. The parties hold this tx in reserve and if need be, pass it around until it has enough signatures. One use of nLockTime is high frequency trades between a set of parties. They can keep updating a tx by unanimous agreement. The party giving money would be the first to sign the next version. If one party stops agreeing to changes, then the last state will be recorded at nLockTime. If desired, a default transaction can be prepared after each version so n-1 parties can push an unresponsive party out. Intermediate transactions do not need to be broadcast. Only the final outcome gets recorded by the network. Just before nLockTime, the parties and a few witness nodes broadcast the highest sequence tx they saw. **Mike Hearn** <mike@plan99.net> Wed, Mar 9, 2011 at 5:39 PM To: Satoshi Nakamoto <satoshin@gmx.com> If you don't know about all txes in existence, I don't know how to do 2). You could only rely on trusting other nodes for that. That trust can be distributed over multiple nodes. Nodes only relay transactions they accept as valid. If you receive inv messages for a tx from all the nodes you're connected to, they're attesting that it's valid and the first spend they saw. _Good point. I was talking about verifying the inputs yes, but it is indeed pointless unless you hear about all open transactions as well. So being able to fetch a CMerkleTx is not important._ Just to reduce surface area. It wouldn't help with increasing tx fee. A tx starts being valid at nLockTime. It wouldn't work to have a tx that stops being valid at a certain time; once a tx ever becomes valid, it must stay valid permanently. See these threads: [http://www.bitcoin.org/smf/index.php?topic=1786.msg22119#msg22119](/home/crrdlx/Dropbox/My%20Docs/books/kicking%20hornets%20nest%20-%20complete%20writings%20of%20satoshi%20nakamoto/edition3_files/_blank) [http://www.bitcoin.org/smf/index.php?topic=2181.msg28729#msg28729](/home/crrdlx/Dropbox/My%20Docs/books/kicking%20hornets%20nest%20-%20complete%20writings%20of%20satoshi%20nakamoto/edition3_files/_blank) _I see. So right now fees are tricky because you have to decide up front what the fee should be, and if you guess too low, there's no way to correct the transaction and though the network will eventually forget it, your wallet still records that you spent the coins. This has already started happening._ _It's for contracts._ _Ah ha. A whole unexplored area of the system opens up before my eyes :-) The concept of forming distributed contracts and escrow transactions without needing to trust an intermediary is a concept nearly as novel as BitCoin itself, I think._ _I have more questions!_ _There's an unfinished part of the protocol that deals with setting up publisher/subscriber channels for distributed routing via the network. What was the purpose of this? Was the idea to have a p2p market or did it have some kind of lower level function, like perhaps broadcasting expected tx fees?_ _There was an interesting discussion of generalizing BitCoin some months ago, but we struggled to fully understand how you planned to achieve it. I think I understood the concept of placing another merkle tree on top of multiple separate chains:_ [_http://www.bitcoin.org/smf/index.php?topic=3414.msg48171#msg48171_](/home/crrdlx/Dropbox/My%20Docs/books/kicking%20hornets%20nest%20-%20complete%20writings%20of%20satoshi%20nakamoto/edition3_files/_blank) _But I didn't understand your comment about having 200 bytes for backwards compatibility. Also, I guess this is obvious, but to be super clear - in your idea the alternative chains would share exactly the same format and sets of verification rules as BitCoin (the same script language etc), so all miners can verify all blocks even if they are non-financial in nature? And then the point of having separate block chains is simply to manage storage costs and bandwidth for client-mode implementations?_ _Thanks!_ **Satoshi Nakamoto** <satoshin@gmx.com> Wed, Mar 9, 2011 at 7:39 PM To: Mike Hearn <mike@plan99.net> _See these threads: _[_http://www.bitcoin.org/smf/index.php?topic=1786.msg22119#msg22119_](/home/crrdlx/Dropbox/My%20Docs/books/kicking%20hornets%20nest%20-%20complete%20writings%20of%20satoshi%20nakamoto/edition3_files/_blank)[_http://www.bitcoin.org/smf/index.php?topic=2181.msg28729#msg28729_](/home/crrdlx/Dropbox/My%20Docs/books/kicking%20hornets%20nest%20-%20complete%20writings%20of%20satoshi%20nakamoto/edition3_files/_blank)_ I see. So right now fees are tricky because you have to decide up front what the fee should be, and if you guess too low, there's no way to correct the transaction and though the network will eventually forget it, your wallet still records that you spent the coins. This has already started happening._ The network won't forget, and the owner's client will keep rebroadcasting it. The overflow transaction was remembered by the network for several months even as the remaining 0.3.8 nodes diminished. Priority includes age, so as a transaction waits it ages and will eventually have enough priority. See one of the links above where I contemplate sending an honest double-spend to increase the fee. It's a lot of work but could be done. I don't think it's worth it right now. The current system, where nodes make sure to include enough fee for current conditions and the network makes sure all transactions get processed eventually, works well enough. Gavin is fixing the oversight where nodes didn't check the priority of their own transactions when writing them. Users still worried about processing speed uncertainty should think of it as encouragement to include a fee. _There's an unfinished part of the protocol that deals with setting up publisher/subscriber channels for distributed routing via the network. What was the purpose of this? Was the idea to have a p2p market or did it have some kind of lower level function, like perhaps broadcasting expected tx fees?_ I was trying to implement an eBay style marketplace built in to the client. Publish/subscribe would be used for broadcasting product offers and ratings/reviews. Your reviews would be weighted by the blocks you've generated. I rightly abandoned it in favour of JSON-RPC, so other authors could implement it externally. The publish/subscribe "meet in the middle" mechanism was an interesting concept, but nothing remains that uses it. It was part of writing code to explore the most technically demanding use cases and make sure Bitcoin could support everything that might be needed in the future, given the locked-in nature of the rules once the block chain started. _There was an interesting discussion of generalizing BitCoin some months ago, but we struggled to fully understand how you planned to achieve it. I think I understood the concept of placing another merkle tree on top of multiple separate chains: _[_http://www.bitcoin.org/smf/index.php?topic=3414.msg48171#msg48171_](/home/crrdlx/Dropbox/My%20Docs/books/kicking%20hornets%20nest%20-%20complete%20writings%20of%20satoshi%20nakamoto/edition3_files/_blank)_ But I didn't understand your comment about having 200 bytes for backwards compatibility. Also, I guess this is obvious, but to be super clear - in your idea the alternative chains would share exactly the same format and sets of verification rules as BitCoin (the same script language etc), so all miners can verify all blocks even if they are non-financial in nature? And then the point of having separate block chains is simply to manage storage costs and bandwidth for client-mode implementations?_ No, other chains do not follow Bitcoin's rules. They are completely independent chains. They share nothing except the miners. The other network's definition of proof-of-work is to make a solved (according to their own chain's difficulty) Bitcoin-format block that has a hash of their own block in it. They don't care if the Bitcoin block is valid or used by Bitcoin, but it allows miners to work both chains at once. Procedure to hash a BitDNS block: - hash the BitDNS block - construct a Bitcoin block - insert the BitDNS hash into the scriptSig of tx 0 in the Bitcoin block - hash the Bitcoin block The BitDNS block is valid if that hash is below BitDNS's target. The BitDNS block needs to have with it about 200 bytes of data needed to reconstruct the Bitcoin block used in the hash: - the Bitcoin block header - the merkle branch to tx 0 - tx 0 (btw, tx 0's prev hash is always 0 so leaving that out saves 32 bytes) Note that it doesn't matter if the fodder "Bitcoin block" was actually valid in the Bitcoin chain, though it could have been. To BitDNS, it's just a bunch of salt necessary to do its convoluted hash calculation. If a miner is only mining for BitDNS and doesn't care about Bitcoin, it would use a blank Bitcoin block of all zeroes (except the nonce). To further expand the idea for extensibility, consider instead of putting the BitDNS block hash in tx 0, you put the root of a merkle tree that includes BitDNS. This is the merkle tree that is conceptually at the top. **Mike Hearn** <mike@plan99.net> Wed, Mar 9, 2011 at 7:52 PM To: Satoshi Nakamoto <satoshin@gmx.com> _Thanks again._ _Hal speculated that you intended to stash the new merkle root in the tx0 scriptSig. Good to know at least he had the right idea :-)_ **Holding coins in an unspendable state for a rolling time window** 6 messages **Mike Hearn** <mike@plan99.net> Mon, Apr 18, 2011 at 11:14 PM To: Satoshi Nakamoto <satoshin@gmx.com> _Hello Satoshi, I hope this mail finds you well. Recently I've been thinking about how BitCoin can help handle internet abuse and would appreciate your thoughts. My "day job" is on the Google abuse team. We make extensive use of phone verification to control outbound spam from our network. Facebook and Craigslist do the same. Phone verification works well because phone numbers are something most people have access to at least one or two of, but rarely more. Yet it has significant downsides - it's expensive (for us), flaky, some people don't like the privacy implications, and some spam is profitable enough that buying lots of SIM cards is worth it. It would be ideal if BitCoins could be put up as collateral against an account. The amount put up would help determine the limits the system placed on your behavior (eg how much mail you can send), in an anonymous and private way. But how to implement this? Burning coins forever is easy, just set the only output to be <pubkey> OP_FALSE. Now you can sign some server-provided challenge with that key and prove you did indeed burn those coins. A key would only be usable with one account so spammers cannot simply put up a huge collateral and then resell signatures generated with that key. If the account was found to be abused it'd be terminated like today, and the coins would be "gone". But people do come and go from these big networks and the thought of losing the coins if you quit Google to run your own mail is unappealing. It would be ideal if coins could be locked up for a period of time such that they cannot be spent until time X, where X can be constantly pushed into the future if the owner desires it but otherwise the coins eventually become spendable again. To verify your Google account, you would take some amount of coins (say 10) and set it up so you cannot spend them for 6 months. The script language has no concept of time. OP_BLOCKNUMBER was ruled out because re-orgs could potentially invalidate entire chains of transactions. But is an OP_DAY feasible? I'm thinking of an opcode that returns the timestamp from the block header, but rounded to the nearest day to handle the natural clock drift seen in the block chain. If it could work then a TX that ties up coins until past a certain day is easy to construct. Updating it so the deadline is constantly moving is harder. A simple brute force solution is to require the user to put up 2x the coins such that at the point the first tx is about to expire and become spendable again, the second tx is created. In this way you always have at least one tx of sufficiently distant deadline to act as collateral. But this is inelegant. A better way would be to introduce a new rule allowing a tx to connect to such an output before the deadline has passed, as long as the output of that tx is once again a deadlined output of the same form. However this is less general than the scripting language so is also somewhat inelegant. What do you think?_ **Satoshi Nakamoto** <satoshin@gmx.com> Wed, Apr 20, 2011 at 11:39 AM To: Mike Hearn <mike@plan99.net> If the script language is not stateless, if it has access to any outside information that changes or varies between nodes, attackers can use it to fork the chain. The only exception is if it is always false before a certain time and permanently true after, which is implemented with nLockTime. Since Google is trusted, couldn't users pay a token deposit to Google and Google pays them back when they close the account? To answer your question though, yes it can be done without using trust: Tx 1 from User pays to a script that requires the signature of both Google and User to spend. Tx 2 (the contract) spends Tx 1 and pays it to User. nLockTime is the time to release the money. Steps: 1) Google gives User a pubkey to use in creating Tx 1. 2) User privately creates Tx 1, does not broadcast it yet. 3) User gives the hash of Tx 1 to Google. 4) Google signs its part of Tx 2, with nLockTime set, and gives it to User. 5) User broadcasts Tx 1. 6) User signs his half of Tx 2 and broadcasts it. With these steps, the user already has Google's signed half of Tx 2 in hand before he broadcasts Tx 1, so he is assured of what bargain he is signing the money to. This is the general pattern for safely signing contracts. Tx 2 is prepared first so the parties know what they're paying into. Tx 1 is broadcast to lock up the money and assign it to Tx 2. In other words, all parties assign their money to a pool that is controlled by the unanimous agreement of the group, but first the group has already signed agreement for the default action to take with the money, or partially signed multiple available options that a party can complete by adding the last signature. By mutual agreement, the parties can always write another version of Tx 2 that releases the money immediately. [Quoted text hidden] **Mike Hearn** <mike@plan99.net> Wed, Apr 20, 2011 at 1:55 PM To: Satoshi Nakamoto <satoshin@gmx.com> _Thanks, that's helpful. I'm understanding contracts better now._ _So the issue with having an OP_TIME/OP_BLOCKNUMBER opcode is not only that the results can change after a re-org (you said that previously), but also that people could use it to produce transactions that cease to be valid entirely after a certain time and cause a fork. Kind of obvious in hindsight._ _Since Google is trusted, couldn't users pay a token deposit to Google and Google pays them back when they close the account?_ _Google and trust is a complicated issue. Lots of people use our services despite having little trust in us. Some people start out trusting us but then read (often sensationalist or wrong) stories in the media that change their minds, and so on. This is one of the problems we have with phone verification ... a few people don't want to give us their phone number._ _For this case it'd probably be OK because trust around data privacy is different to trust around obeying contracts. I'm sure nobody would doubt that Google will pay them back - I bet we'd have an even better credit rating than the US Government in that sense :-) But we have quite a high rate of false positives with our verifications and some people would suspect we were accidentally verifying users in order to accumulate big piles of coins with which to earn interest. I've seen much sillier conspiracy theories gain traction._ _Besides, avoiding the need to trust big, complex institutions is much more BitCoin-ish. And I correctly suspected there was a way to do it I didn't understand yet so it's a good chance to learn more about BitCoin._ _To answer your question though, yes it can be done without using trust_ _If I wrote a wiki page on how to build contracts with BitCoin, would you mind reviewing it?_ _I'm thinking it might be a good idea to re-enable transaction replacement soon because as the network grows, it will become harder and harder to upgrade. In one sense this is good as it makes it hard to change the fundamental rules of the system. On the other hand, we risk having a protocol which has many unused features because they aren't widely supported enough. HTTP suffered this fate with many of its verbs as well as features like pipelining._ _Did you have any list of tasks for re-activation, some kind of audit or finishing off some code?_ _I had a few other things on my mind (as always). One is, are you planning on rejoining the community at some point (eg for code reviews), or is your plan to permanently step back from the limelight? One reason I'm peppering you with questions is I worry that much of BitCoins potential lies in careful use of currently inactive features, but there's little guidance on how to do it. And frankly, I don't think I'm smart enough to figure it all out on my own. Maybe theymos is, he seems to understand it well. But if one day you leave entirely, parts of the protocol might fall into disuse, which would be a shame._ _Another is the economics of mining after the transition to a fully fee based system. Right now difficulty is roughly a function of the USD/BTC exchange rate and per-block inflation. When mining reward is set by the market, it might be possible for a "Tragedy of the commons" to occur in which everyone benefits from a high difficulty, but nobody specifically wants to pay fees to get it. Besides, valuing difficulty is quite hard as you never know what the capabilities of attackers are until it's too late. Would it be possible for fees to trend towards zero over time as some miner is always willing to accept cheaper transactions and as miners drop out, the difficulty adjusts so the delays never get too bad to tolerate?_ _As always thanks for your insights._ **Satoshi Nakamoto** <satoshin@gmx.com> Sat, Apr 23, 2011 at 3:40 PM To: Mike Hearn <mike@plan99.net> _I had a few other things on my mind (as always). One is, are you planning on rejoining the community at some point (eg for code reviews), or is your plan to permanently step back from the limelight?_ I've moved on to other things. It's in good hands with Gavin and everyone. I do hope your BitcoinJ continues to be developed into an alternative client. It gives Java devs something to work on, and it's easier with a simpler foundation that doesn't have to do everything. It'll get critical mass when impatient new users can get started using it while the other one is still downloading the block chain. ##### P2P Foundation #### Bitcoin open source implementation of P2P currency ##### _2014-03-07 01:17:00 UTC_ - [-](http://p2pfoundation.ning.com/xn/detail/2003008:Comment:52186) I am not Dorian Nakamoto. _Editor’s note: this comment was apparently made in response to a March 6, 2014 Newsweek article that Dorian Nakamoto was the real Satoshi Nakamoto of Bitcoin fame. The post is debated as to its authenticity. Some say that Satoshi’s account was hacked and that this was not actually written by Satoshi Nakamoto._ ---- Kicking the Hornet’s Nest: The Complete Writings, Emails, and Forum Posts of Satoshi Nakamoto, the Founder of Bitcoin and Cryptocurrency ![](https://image.nostr.build/c046a1836552e0eab137e83cf144ba089266f5cd65160b2a72420dbcd9b434ad.jpg) All formats and links are available at [https://hive.blog/@crrdlx/satoshi](https://hive.blog/@crrdlx/satoshi) ----

256260msg22119msg28729msg48171_msg22119_msg28729_

Kicking the Hornet's Nest - part 22 - the end

# Kicking the Hornet's Nest - third edition - part 22 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 506 - 527 (the end) ---- **Satoshi Nakamoto** <satoshin@gmx.com> Fri, Jan 7, 2011 at 1:00 PM To: Mike Hearn <mike@plan99.net> _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._ That's great! The first client-only implementation will really start to move things to the next step. Is it going to be open source, or Google proprietary? **Mike Hearn** <mike@plan99.net> Fri, Jan 7, 2011 at 1:24 PM To: Satoshi Nakamoto <satoshin@gmx.com> > That's great! The first client-only implementation will really start to > move things to the next step. Is it going to be open source, or Google > proprietary? _Open source. It has to be - I am developing it as a personal project in my spare time and Googles policy is that this is only allowed if you open source the results. But I would have done that anyway. I managed to spend my first coins on the testnet with my app a few days ago, hopefully will get another chance to make progress this weekend. Probably will have something to show publically sometime in Feb, touch wood._ **Satoshi Nakamoto** <satoshin@gmx.com> Mon, Jan 10, 2011 at 4:34 PM To: Mike Hearn <mike@plan99.net> Open source. Perfect. Once your code shows how to simplify it down, other authors can follow your lead. Client is a less daunting challenge than full implementation. If it's within reach of more developers, they'll come up with more polished UI and other things I didn't think of. I expect the original software will become the industrial old thing used by GPU farms and pool servers. BTW, later a good feature for a client version is to keep your private keys encrypted and you give your password each time you send. _I managed to spend my first coins on the testnet with my app a few days ago, hopefully will get another chance to make progress this weekend. Probably will have something to show publically sometime in Feb, touch wood._ Great, keep me updated. _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._ It works out to an even 10 minutes per block: 21000000 / (50 BTC * 24hrs * 365days * 4years * 2) = 5.99 blocks/hour I fudged it to 364.58333 days/year. The halving of 50 BTC to 25 BTC is after 210000 blocks or around 3.9954 years, which is approximate anyway based on the retargeting mechanism's best effort. I thought about 100 BTC and 42 million, but 42 million seemed high. I wanted typical amounts to be in a familiar range. If you're tossing around 100000 units, it doesn't feel scarce. The brain is better able to work with numbers from 0.01 to 1000. If it gets really big, the decimal can move two places and cents become the new coins. **Mike Hearn** <mike@plan99.net> Mon, Jan 10, 2011 at 4:48 PM To: Satoshi Nakamoto <satoshin@gmx.com> _Ah, of course, that makes sense._ _By the way, if you didn't see it already, there's a discussion on the security of secp256k1 on the forum:_ [_http://www.bitcoin.org/smf/index.php?topic=2699.0_](http://www.bitcoin.org/smf/index.php?topic=2699.0) _Hal (i presume this is Hal Finney) seems to think the curve is at higher risk of attack than random curves. I guess you chose secp256k1 for the mentioned performance improvement?_ _[Quoted text hidden]_ **Satoshi Nakamoto** <satoshin@gmx.com> Mon, Jan 10, 2011 at 8:47 PM To: Mike Hearn <mike@plan99.net> _By the way, if you didn't see it already, there's a discussion on the security of secp256k1 on the forum: _[_http://www.bitcoin.org/smf/index.php?topic=2699.0_](http://www.bitcoin.org/smf/index.php?topic=2699.0)_ Hal (i presume this is Hal Finney)_ Yes, it's him. He was supportive on the Cryptography list and ran one of the first nodes. _seems to think the curve is at higher risk of attack than random curves. I guess you chose secp256k1 for the mentioned performance improvement?_ I must admit, this project was 2 years of development before release, and I could only spend so much time on each of the many issues. I found guidance on the recommended size for SHA and RSA, but nothing on ECDSA which was relatively new. I took the recommended key size for RSA and converted to equivalent key size for ECDSA, but then increased it so the whole app could be said to be 256-bit security. I didn't find anything to recommend a curve type so I just... picked one. Hopefully there is enough key size to make up for any deficiency. At the time, I was concerned whether the bandwidth and storage sizes would be practical even with ECDSA. RSA's huge keys were out of the question. Storage and bandwidth seemed tighter back then. I felt the size was either only just becoming practical, or would be soon. When I presented it, I was surprised nobody else was concerned about size, though I was also surprised how many issues they argued, and more surprised that every single one was something I had thought of and solved. As it turns out, ECDSA verification time may be the greater bottleneck. (In my tests, OpenSSL was taking 3.5ms per ECDSA verify, or about 285 verifies per second) Client versions bypass the problem. As things have evolved, the number of people who need to run full nodes is less than I originally imagined. The network would be fine with a small number of nodes if processing load becomes heavy. **Martii Malmi (AKA Sirius) “COPA trial” email #256** **Date: Tue, 25 Jan 2011 18:34:03 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Fwd: Bitcoin question** **To: mmalmi@cc.hut.fi** The paper was published in 2008. Someone needs to correct Wikipedia; it incorrectly says the paper was published in 2009. The paper was released earlier than the software. _mmalmi@cc.hut.fi wrote:_ _> Can you comment on this?_ _>_ _> ----- Forwarded message from cjwells_1@yahoo.com -----_ _> Date: Mon, 24 Jan 2011 00:32:48 -0800 (PST)_ _> From: "Constance J. Wells" <cjwells_1@yahoo.com>_ _> Reply-To: "Constance J. Wells" <cjwells_1@yahoo.com>_ _> Subject: Re:_ _> To: mmalmi@cc.hut.fi_ _>_ _> Martti,_ _> Thank you for the pdf. It looks great. I do not see a date on it. When_ _> was it written?_ _>_ _> Mr. Mark Herpel of Digital Gold Currency Magazine brought Bitcoin to my_ _> attention for inclusion in my thesis. The thesis working title is:_ _> Digital Currency Systems: Emerging B2B e-Commerce Alternative During_ _> Monetary Crisis in the United States. I discuss the five types of_ _> systems per Mr. Herpels suggestion._ _>_ _> Appreciate it and hope to talk soon._ _>_ _> C._ _>_ _> Constance J. Wells, CeM, PMP: PMI certified_ _> Denver, CO U.S.A._ _> 303-730-6609_ _>_ _> --- On Mon, 1/24/11, mmalmi@cc.hut.fi <mmalmi@cc.hut.fi> wrote:_ _>_ _> From: mmalmi@cc.hut.fi <mmalmi@cc.hut.fi>_ _> Subject: Re:_ _> To: "Constance J. Wells" <cjwells_1@yahoo.com>_ _> Date: Monday, January 24, 2011, 1:22 AM_ _>_ _> Hi Constance,_ _>_ _> Thanks for your interest in Bitcoin, feel free to cite. There's also_ _> Satoshi Nakamoto's paper available at http://www.bitcoin.org/bitcoin.pdf_ _> if you want something with a more formal touch. Please let us know when_ _> your thesis is finished!_ _>_ _>_ _> -Martti_ _>_ _>> Martti Malmi_ _>> Currently I am a full time student at-_ _>> http://info.aspen.edu/_ _>> Aspen University, in Denver, CO, 303-333-4224._ _>> Masters of Science in Technology and Innovation._ _>>_ _>> I am writing my Thesis under the subject heading, digital currency_ _>> systems. May I cite your site in my Thesis?_ _>>_ _>> Thank you._ _>> Constance_ _>> Constance J. Wells, CeM, PMP: PMI certified_ _>> Denver, CO U.S.A._ _>> 303-730-6609_ _>>_ **Martii Malmi (AKA Sirius) “COPA trial” email #260** **Date: Tue, 22 Feb 2011 19:49:19 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: 0.3.20 release : shipped** **To: Gavin Andresen <gavinandresen@gmail.com>, Martti Malmi <mmalmi@cc.hut.fi>** _> I have not sent a message to the sourceforge bitcoin-list mailing list_ _> because I don't think I have permission; Satoshi, can you give me_ _> permission, encrypt the mailman password with my public key and send_ _> it to me, or just post the announcement?_ Martti should give you the Drupal admin password. Any subscriber can post to bitcoin-list. Here's the admin password in case you need it later. Gavin: -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.7 (MingW32) - WinPT 1.2.0 hQIOAxfAPINgyySWEAf9GHyuMqxkhoBe96hbHoFPIR4ORpMS/v2mpCT70UmgTt46 GVO5MeEOFE4JUqltYUaAE2u7e7+BbyNFeNk4o0kwJIWUXbRoBHj59vx+yzmeRLd9 YxTWxZA2zOVcYcYoDkiYAatwlQWQefzwYFcCnBSSsY1F9XLHMtLqNadhftOregoE 5Prhjk4ScAEOAmJ2CfYvWLD6FPAe4s6nXzP656oQghMgUivYoowHAjGUSvd8f1Qb fkV0isGIYCpHCOSZDZpysPCm63ibEeiuylvkT7Ayj2HoonqypFdv05mtyS7Jtq6a s06UqjLSyICoGJVk4x5HZhusgmbqViLvb6gM+iadbQf/U9KEKA5KyF0JvjYlx97k Bm7WpBIxKnP6Migl/Otol85EYt9rWN0lozLGw5Ko1JTZzXv3RrTsJafUYnDyAvtR 20JExoG84LatTeFiTqVWHiWZbYG2ECJHTO6jOmITvNvq/OgCID4hQvjvNQiXghae qzolzmZVEwDGAybWJoSvAsXjDWbAyHt9WJztHPgVRxgTBrnhoLAX0FwKGTCr7L/t emVEUqgEf3WqmljD+cCXSNVloQxGmPvaSsbITIZvX/emwq4MAC+SuRmJLJp6kSmu UhkxZMipvYHfyBPXoonAM7oYXNIaFQryS66UlEziSUevvU8TXiZMeUyyiMirOBXC itKhAedpc7NQYG+/KohTS0U9QfdygBfE2o6M96tRKFdMmbQz3Gyq0BaBpp98+ve+ VOVp90mYv9zq43G7tHnZektEjGzplHj0HzWhfbiy2dBrDGhkByYN4G6kX0JvU4ZX /ixmbOf5qZPqcgmz7fYDxKnkUQVumoEIfNXrUlAPcI2Ql9TnY0NIg9ZIVOGeT4lE 80kYloQVdCdnrJ7yLWexO0W1kSs= =S7eV -----END PGP MESSAGE----- Martti: -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.7 (MingW32) - WinPT 1.2.0 hQEMA+kEt/4bukJEAQgAlt5/Ks5pZPeusK0yefyMn7BqIVcOVHDaXbnf4dLKqq5J 6bKyMlkyYjhm1itZabi+IaV9k+1r7Wo50qOqfZNCSmG63hX3asXWd7QxThj4KDxr fvuUfiduf2AyZcB4r/baw1hsdC3VGxQutU0ookuJqfvCIse77clS2WimKJ5hrh5G KVdGApk3TxbILknalIs3mUw81sL0nvbO/aNrHiiNj44YU3Ehf5CieEJInHeYGTsJ AABLZcH6B7nymA8D4nrAAnDcjcSE8+iWMOtzI2duCHKtA+LVJOsg8n/zHqK9SZNF w+Xud7mBi/ZvnFGwCZh7cqJ/jZhNLLTQHiLr8M+i7dKhAekFho8aarOV9V4Cp2hT a8bQdbgwsednyjCzaq+C8xU+aYJcAV95qK6QG2hlT8xpDU2KHBHWIjDmPKlzgvKb 8/dQo5VDvtQkdyvrd9pMJeOUxFKEVW5ph+4LzKjKEWE1kJhzAwbxQMNKkXLzZJIa hJMNAVHDjnYcuI8EgJT+TjH2Kx+KwHX/OEOFaDXGP7XwMOuVZTVtbXnsJ24SFa1i m4U= =0TBL -----END PGP MESSAGE----- **Open sourced my Java SPV impl** 10 messages **Mike Hearn** <mike@plan99.net> Mon, Mar 7, 2011 at 2:13 PM To: Satoshi Nakamoto <satoshin@gmx.com> _Hi Satoshi, I hope you are doing well. I finally got all the lawyers happy enough to release BitCoinJ under the Google name using the Apache 2 license: _[_http://www.bitcoin.org/smf/index.php?topic=4236.0_](http://www.bitcoin.org/smf/index.php?topic=4236.0)_ It's incomplete - notably it doesn't properly handle block chain splits yet - but the rest is coming. I put a lot of work into documentation and comments so hopefully it'll open up BitCoin to a new audience who weren't able to understand/build the current code. Over the next month or two I'll be finishing off some of the bigger missing pieces for a full client-mode implementation. I know you are busy right now but I'm hoping you can find time to answer a few questions I had. As part of doing full SPV I'm thinking of adding a getmerklebranch message to the protocol. This would return a set of {blockhash, branch} pairs given tx hashes, so allowing verification of a broadcast transaction before it was incorporated into a block without storing the full chain. Does that approach sound good to you? Also, I've been thinking of exploring different transaction types lately, eg by removing the IsStandard() checks for the testnet. It's clear you put a lot of thought into transactions beyond simply moving coins around up front, but unfortunately none of it was in the paper or documented in the code. Escrow, multi-pay and so on are all interesting but I was wondering if you could compile a list of ideas for things we can do with the scripting language at some point. Finally, the code that allows for transaction replacement has been disabled but the comment doesn't say why. Is this just to reduce the attack surface/complexity or is there a deeper reason? I haven't fully understood why sequence numbers are a property of the tx inputs rather than the tx itself. Hope you can find the time/energy to rejoin us soon! I don't know if you've seen this: _[_http://bitcoin.sipa.be/speed-lin.png_](http://bitcoin.sipa.be/speed-lin.png)_ but it's exciting times for the network! thanks! __/mike_ **Satoshi Nakamoto** <satoshin@gmx.com> Wed, Mar 9, 2011 at 5:15 PM To: Mike Hearn <mike@plan99.net> _I hope you are doing well. I finally got all the lawyers happy enough to release BitCoinJ under the Google name using the Apache 2 license: It's incomplete - notably it doesn't properly handle block chain splits yet - but the rest is coming. I put a lot of work into documentation and comments so hopefully it'll open up BitCoin to a new audience who weren't able to understand/build the current code. Over the next month or two I'll be finishing off some of the bigger missing pieces for a full client-mode implementation._ That's great news! Much complexity can be left behind in a clean rewrite with only client requirements, and it opens it to Java developers too. _I know you are busy right now but I'm hoping you can find time to answer a few questions I had._ I'm happy to answer any questions. _As part of doing full SPV I'm thinking of adding a getmerklebranch message to the protocol. This would return a set of {blockhash, branch} pairs_ That's a CMerkleTx _given tx hashes, so allowing verification of a broadcast transaction before it was incorporated into a block without storing the full chain. Does that approach sound good to you?_ I don't understand. A merkle branch links a tx back to a block, which only has significance if the block exhibits proof-of-work. Linking back to an as-yet unsolved block proves nothing. Network nodes are able to verify 0-conf txes because they have the complete tx index, so they can: 1) verify signatures against dependencies. 2) say that they haven't seen another spend yet, because they know about every tx in existence. Are you talking about CMerkleTxes for the tx's dependencies? That would get part 1), but not part 2). If you don't know about all txes in existence, I don't know how to do 2). You could only rely on trusting other nodes for that. That trust can be distributed over multiple nodes. Nodes only relay transactions they accept as valid. If you receive inv messages for a tx from all the nodes you're connected to, they're attesting that it's valid and the first spend they saw. _Also, I've been thinking of exploring different transaction types lately, eg by removing the IsStandard() checks for the testnet._ Very good idea. That should definitely be allowed on -testnet. _It's clear you put a lot of thought into transactions beyond simply moving coins around up front, but unfortunately none of it was in the paper or documented in the code. Escrow, multi-pay and so on are all interesting but I was wondering if you could compile a list of ideas for things we can do with the scripting language at some point. Finally, the code that allows for transaction replacement has been disabled but the comment doesn't say why. Is this just to reduce the attack surface/complexity or is there a deeper reason?_ Just to reduce surface area. It wouldn't help with increasing tx fee. A tx starts being valid at nLockTime. It wouldn't work to have a tx that stops being valid at a certain time; once a tx ever becomes valid, it must stay valid permanently. See these threads: [http://www.bitcoin.org/smf/index.php?topic=1786.msg22119#msg22119](/home/crrdlx/Dropbox/My%20Docs/books/kicking%20hornets%20nest%20-%20complete%20writings%20of%20satoshi%20nakamoto/edition3_files/_blank) [http://www.bitcoin.org/smf/index.php?topic=2181.msg28729#msg28729](/home/crrdlx/Dropbox/My%20Docs/books/kicking%20hornets%20nest%20-%20complete%20writings%20of%20satoshi%20nakamoto/edition3_files/_blank) _I haven't fully understood why sequence numbers are a property of the tx inputs rather than the tx itself._ It's for contracts. An unrecorded open transaction can keep being replaced until nLockTime. It may contain payments by multiple parties. Each input owner signs their input. For a new version to be written, each must sign a higher sequence number (see IsNewerThan). By signing, an input owner says "I agree to put my money in, if everyone puts their money in and the outputs are this." There are other options in SignatureHash such as SIGHASH_SINGLE which means "I agree, as long as this one output (i.e. mine) is what I want, I don't care what you do with the other outputs.". If that's written with a high nSequenceNumber, the party can bow out of the negotiation except for that one stipulation, or sign SIGHASH_NONE and bow out completely. The parties could create a pre-agreed default option by creating a higher nSequenceNumber tx using OP_CHECKMULTISIG that requires a subset of parties to sign to complete the signature. The parties hold this tx in reserve and if need be, pass it around until it has enough signatures. One use of nLockTime is high frequency trades between a set of parties. They can keep updating a tx by unanimous agreement. The party giving money would be the first to sign the next version. If one party stops agreeing to changes, then the last state will be recorded at nLockTime. If desired, a default transaction can be prepared after each version so n-1 parties can push an unresponsive party out. Intermediate transactions do not need to be broadcast. Only the final outcome gets recorded by the network. Just before nLockTime, the parties and a few witness nodes broadcast the highest sequence tx they saw. **Mike Hearn** <mike@plan99.net> Wed, Mar 9, 2011 at 5:39 PM To: Satoshi Nakamoto <satoshin@gmx.com> If you don't know about all txes in existence, I don't know how to do 2). You could only rely on trusting other nodes for that. That trust can be distributed over multiple nodes. Nodes only relay transactions they accept as valid. If you receive inv messages for a tx from all the nodes you're connected to, they're attesting that it's valid and the first spend they saw. _Good point. I was talking about verifying the inputs yes, but it is indeed pointless unless you hear about all open transactions as well. So being able to fetch a CMerkleTx is not important._ Just to reduce surface area. It wouldn't help with increasing tx fee. A tx starts being valid at nLockTime. It wouldn't work to have a tx that stops being valid at a certain time; once a tx ever becomes valid, it must stay valid permanently. See these threads: [http://www.bitcoin.org/smf/index.php?topic=1786.msg22119#msg22119](/home/crrdlx/Dropbox/My%20Docs/books/kicking%20hornets%20nest%20-%20complete%20writings%20of%20satoshi%20nakamoto/edition3_files/_blank) [http://www.bitcoin.org/smf/index.php?topic=2181.msg28729#msg28729](/home/crrdlx/Dropbox/My%20Docs/books/kicking%20hornets%20nest%20-%20complete%20writings%20of%20satoshi%20nakamoto/edition3_files/_blank) _I see. So right now fees are tricky because you have to decide up front what the fee should be, and if you guess too low, there's no way to correct the transaction and though the network will eventually forget it, your wallet still records that you spent the coins. This has already started happening._ _It's for contracts._ _Ah ha. A whole unexplored area of the system opens up before my eyes :-) The concept of forming distributed contracts and escrow transactions without needing to trust an intermediary is a concept nearly as novel as BitCoin itself, I think._ _I have more questions!_ _There's an unfinished part of the protocol that deals with setting up publisher/subscriber channels for distributed routing via the network. What was the purpose of this? Was the idea to have a p2p market or did it have some kind of lower level function, like perhaps broadcasting expected tx fees?_ _There was an interesting discussion of generalizing BitCoin some months ago, but we struggled to fully understand how you planned to achieve it. I think I understood the concept of placing another merkle tree on top of multiple separate chains:_ [_http://www.bitcoin.org/smf/index.php?topic=3414.msg48171#msg48171_](/home/crrdlx/Dropbox/My%20Docs/books/kicking%20hornets%20nest%20-%20complete%20writings%20of%20satoshi%20nakamoto/edition3_files/_blank) _But I didn't understand your comment about having 200 bytes for backwards compatibility. Also, I guess this is obvious, but to be super clear - in your idea the alternative chains would share exactly the same format and sets of verification rules as BitCoin (the same script language etc), so all miners can verify all blocks even if they are non-financial in nature? And then the point of having separate block chains is simply to manage storage costs and bandwidth for client-mode implementations?_ _Thanks!_ **Satoshi Nakamoto** <satoshin@gmx.com> Wed, Mar 9, 2011 at 7:39 PM To: Mike Hearn <mike@plan99.net> _See these threads: _[_http://www.bitcoin.org/smf/index.php?topic=1786.msg22119#msg22119_](/home/crrdlx/Dropbox/My%20Docs/books/kicking%20hornets%20nest%20-%20complete%20writings%20of%20satoshi%20nakamoto/edition3_files/_blank)[_http://www.bitcoin.org/smf/index.php?topic=2181.msg28729#msg28729_](/home/crrdlx/Dropbox/My%20Docs/books/kicking%20hornets%20nest%20-%20complete%20writings%20of%20satoshi%20nakamoto/edition3_files/_blank)_ I see. So right now fees are tricky because you have to decide up front what the fee should be, and if you guess too low, there's no way to correct the transaction and though the network will eventually forget it, your wallet still records that you spent the coins. This has already started happening._ The network won't forget, and the owner's client will keep rebroadcasting it. The overflow transaction was remembered by the network for several months even as the remaining 0.3.8 nodes diminished. Priority includes age, so as a transaction waits it ages and will eventually have enough priority. See one of the links above where I contemplate sending an honest double-spend to increase the fee. It's a lot of work but could be done. I don't think it's worth it right now. The current system, where nodes make sure to include enough fee for current conditions and the network makes sure all transactions get processed eventually, works well enough. Gavin is fixing the oversight where nodes didn't check the priority of their own transactions when writing them. Users still worried about processing speed uncertainty should think of it as encouragement to include a fee. _There's an unfinished part of the protocol that deals with setting up publisher/subscriber channels for distributed routing via the network. What was the purpose of this? Was the idea to have a p2p market or did it have some kind of lower level function, like perhaps broadcasting expected tx fees?_ I was trying to implement an eBay style marketplace built in to the client. Publish/subscribe would be used for broadcasting product offers and ratings/reviews. Your reviews would be weighted by the blocks you've generated. I rightly abandoned it in favour of JSON-RPC, so other authors could implement it externally. The publish/subscribe "meet in the middle" mechanism was an interesting concept, but nothing remains that uses it. It was part of writing code to explore the most technically demanding use cases and make sure Bitcoin could support everything that might be needed in the future, given the locked-in nature of the rules once the block chain started. _There was an interesting discussion of generalizing BitCoin some months ago, but we struggled to fully understand how you planned to achieve it. I think I understood the concept of placing another merkle tree on top of multiple separate chains: _[_http://www.bitcoin.org/smf/index.php?topic=3414.msg48171#msg48171_](/home/crrdlx/Dropbox/My%20Docs/books/kicking%20hornets%20nest%20-%20complete%20writings%20of%20satoshi%20nakamoto/edition3_files/_blank)_ But I didn't understand your comment about having 200 bytes for backwards compatibility. Also, I guess this is obvious, but to be super clear - in your idea the alternative chains would share exactly the same format and sets of verification rules as BitCoin (the same script language etc), so all miners can verify all blocks even if they are non-financial in nature? And then the point of having separate block chains is simply to manage storage costs and bandwidth for client-mode implementations?_ No, other chains do not follow Bitcoin's rules. They are completely independent chains. They share nothing except the miners. The other network's definition of proof-of-work is to make a solved (according to their own chain's difficulty) Bitcoin-format block that has a hash of their own block in it. They don't care if the Bitcoin block is valid or used by Bitcoin, but it allows miners to work both chains at once. Procedure to hash a BitDNS block: - hash the BitDNS block - construct a Bitcoin block - insert the BitDNS hash into the scriptSig of tx 0 in the Bitcoin block - hash the Bitcoin block The BitDNS block is valid if that hash is below BitDNS's target. The BitDNS block needs to have with it about 200 bytes of data needed to reconstruct the Bitcoin block used in the hash: - the Bitcoin block header - the merkle branch to tx 0 - tx 0 (btw, tx 0's prev hash is always 0 so leaving that out saves 32 bytes) Note that it doesn't matter if the fodder "Bitcoin block" was actually valid in the Bitcoin chain, though it could have been. To BitDNS, it's just a bunch of salt necessary to do its convoluted hash calculation. If a miner is only mining for BitDNS and doesn't care about Bitcoin, it would use a blank Bitcoin block of all zeroes (except the nonce). To further expand the idea for extensibility, consider instead of putting the BitDNS block hash in tx 0, you put the root of a merkle tree that includes BitDNS. This is the merkle tree that is conceptually at the top. **Mike Hearn** <mike@plan99.net> Wed, Mar 9, 2011 at 7:52 PM To: Satoshi Nakamoto <satoshin@gmx.com> _Thanks again._ _Hal speculated that you intended to stash the new merkle root in the tx0 scriptSig. Good to know at least he had the right idea :-)_ **Holding coins in an unspendable state for a rolling time window** 6 messages **Mike Hearn** <mike@plan99.net> Mon, Apr 18, 2011 at 11:14 PM To: Satoshi Nakamoto <satoshin@gmx.com> _Hello Satoshi, I hope this mail finds you well. Recently I've been thinking about how BitCoin can help handle internet abuse and would appreciate your thoughts. My "day job" is on the Google abuse team. We make extensive use of phone verification to control outbound spam from our network. Facebook and Craigslist do the same. Phone verification works well because phone numbers are something most people have access to at least one or two of, but rarely more. Yet it has significant downsides - it's expensive (for us), flaky, some people don't like the privacy implications, and some spam is profitable enough that buying lots of SIM cards is worth it. It would be ideal if BitCoins could be put up as collateral against an account. The amount put up would help determine the limits the system placed on your behavior (eg how much mail you can send), in an anonymous and private way. But how to implement this? Burning coins forever is easy, just set the only output to be <pubkey> OP_FALSE. Now you can sign some server-provided challenge with that key and prove you did indeed burn those coins. A key would only be usable with one account so spammers cannot simply put up a huge collateral and then resell signatures generated with that key. If the account was found to be abused it'd be terminated like today, and the coins would be "gone". But people do come and go from these big networks and the thought of losing the coins if you quit Google to run your own mail is unappealing. It would be ideal if coins could be locked up for a period of time such that they cannot be spent until time X, where X can be constantly pushed into the future if the owner desires it but otherwise the coins eventually become spendable again. To verify your Google account, you would take some amount of coins (say 10) and set it up so you cannot spend them for 6 months. The script language has no concept of time. OP_BLOCKNUMBER was ruled out because re-orgs could potentially invalidate entire chains of transactions. But is an OP_DAY feasible? I'm thinking of an opcode that returns the timestamp from the block header, but rounded to the nearest day to handle the natural clock drift seen in the block chain. If it could work then a TX that ties up coins until past a certain day is easy to construct. Updating it so the deadline is constantly moving is harder. A simple brute force solution is to require the user to put up 2x the coins such that at the point the first tx is about to expire and become spendable again, the second tx is created. In this way you always have at least one tx of sufficiently distant deadline to act as collateral. But this is inelegant. A better way would be to introduce a new rule allowing a tx to connect to such an output before the deadline has passed, as long as the output of that tx is once again a deadlined output of the same form. However this is less general than the scripting language so is also somewhat inelegant. What do you think?_ **Satoshi Nakamoto** <satoshin@gmx.com> Wed, Apr 20, 2011 at 11:39 AM To: Mike Hearn <mike@plan99.net> If the script language is not stateless, if it has access to any outside information that changes or varies between nodes, attackers can use it to fork the chain. The only exception is if it is always false before a certain time and permanently true after, which is implemented with nLockTime. Since Google is trusted, couldn't users pay a token deposit to Google and Google pays them back when they close the account? To answer your question though, yes it can be done without using trust: Tx 1 from User pays to a script that requires the signature of both Google and User to spend. Tx 2 (the contract) spends Tx 1 and pays it to User. nLockTime is the time to release the money. Steps: 1) Google gives User a pubkey to use in creating Tx 1. 2) User privately creates Tx 1, does not broadcast it yet. 3) User gives the hash of Tx 1 to Google. 4) Google signs its part of Tx 2, with nLockTime set, and gives it to User. 5) User broadcasts Tx 1. 6) User signs his half of Tx 2 and broadcasts it. With these steps, the user already has Google's signed half of Tx 2 in hand before he broadcasts Tx 1, so he is assured of what bargain he is signing the money to. This is the general pattern for safely signing contracts. Tx 2 is prepared first so the parties know what they're paying into. Tx 1 is broadcast to lock up the money and assign it to Tx 2. In other words, all parties assign their money to a pool that is controlled by the unanimous agreement of the group, but first the group has already signed agreement for the default action to take with the money, or partially signed multiple available options that a party can complete by adding the last signature. By mutual agreement, the parties can always write another version of Tx 2 that releases the money immediately. [Quoted text hidden] **Mike Hearn** <mike@plan99.net> Wed, Apr 20, 2011 at 1:55 PM To: Satoshi Nakamoto <satoshin@gmx.com> _Thanks, that's helpful. I'm understanding contracts better now._ _So the issue with having an OP_TIME/OP_BLOCKNUMBER opcode is not only that the results can change after a re-org (you said that previously), but also that people could use it to produce transactions that cease to be valid entirely after a certain time and cause a fork. Kind of obvious in hindsight._ _Since Google is trusted, couldn't users pay a token deposit to Google and Google pays them back when they close the account?_ _Google and trust is a complicated issue. Lots of people use our services despite having little trust in us. Some people start out trusting us but then read (often sensationalist or wrong) stories in the media that change their minds, and so on. This is one of the problems we have with phone verification ... a few people don't want to give us their phone number._ _For this case it'd probably be OK because trust around data privacy is different to trust around obeying contracts. I'm sure nobody would doubt that Google will pay them back - I bet we'd have an even better credit rating than the US Government in that sense :-) But we have quite a high rate of false positives with our verifications and some people would suspect we were accidentally verifying users in order to accumulate big piles of coins with which to earn interest. I've seen much sillier conspiracy theories gain traction._ _Besides, avoiding the need to trust big, complex institutions is much more BitCoin-ish. And I correctly suspected there was a way to do it I didn't understand yet so it's a good chance to learn more about BitCoin._ _To answer your question though, yes it can be done without using trust_ _If I wrote a wiki page on how to build contracts with BitCoin, would you mind reviewing it?_ _I'm thinking it might be a good idea to re-enable transaction replacement soon because as the network grows, it will become harder and harder to upgrade. In one sense this is good as it makes it hard to change the fundamental rules of the system. On the other hand, we risk having a protocol which has many unused features because they aren't widely supported enough. HTTP suffered this fate with many of its verbs as well as features like pipelining._ _Did you have any list of tasks for re-activation, some kind of audit or finishing off some code?_ _I had a few other things on my mind (as always). One is, are you planning on rejoining the community at some point (eg for code reviews), or is your plan to permanently step back from the limelight? One reason I'm peppering you with questions is I worry that much of BitCoins potential lies in careful use of currently inactive features, but there's little guidance on how to do it. And frankly, I don't think I'm smart enough to figure it all out on my own. Maybe theymos is, he seems to understand it well. But if one day you leave entirely, parts of the protocol might fall into disuse, which would be a shame._ _Another is the economics of mining after the transition to a fully fee based system. Right now difficulty is roughly a function of the USD/BTC exchange rate and per-block inflation. When mining reward is set by the market, it might be possible for a "Tragedy of the commons" to occur in which everyone benefits from a high difficulty, but nobody specifically wants to pay fees to get it. Besides, valuing difficulty is quite hard as you never know what the capabilities of attackers are until it's too late. Would it be possible for fees to trend towards zero over time as some miner is always willing to accept cheaper transactions and as miners drop out, the difficulty adjusts so the delays never get too bad to tolerate?_ _As always thanks for your insights._ **Satoshi Nakamoto** <satoshin@gmx.com> Sat, Apr 23, 2011 at 3:40 PM To: Mike Hearn <mike@plan99.net> _I had a few other things on my mind (as always). One is, are you planning on rejoining the community at some point (eg for code reviews), or is your plan to permanently step back from the limelight?_ I've moved on to other things. It's in good hands with Gavin and everyone. I do hope your BitcoinJ continues to be developed into an alternative client. It gives Java devs something to work on, and it's easier with a simpler foundation that doesn't have to do everything. It'll get critical mass when impatient new users can get started using it while the other one is still downloading the block chain. ##### P2P Foundation #### Bitcoin open source implementation of P2P currency ##### _2014-03-07 01:17:00 UTC_ - [-](http://p2pfoundation.ning.com/xn/detail/2003008:Comment:52186) I am not Dorian Nakamoto. _Editor’s note: this comment was apparently made in response to a March 6, 2014 Newsweek article that Dorian Nakamoto was the real Satoshi Nakamoto of Bitcoin fame. The post is debated as to its authenticity. Some say that Satoshi’s account was hacked and that this was not actually written by Satoshi Nakamoto._ Kicking the Hornet’s Nest: The Complete Writings, Emails, and Forum Posts of Satoshi Nakamoto, the Founder of Bitcoin and Cryptocurrency ![](https://image.nostr.build/c046a1836552e0eab137e83cf144ba089266f5cd65160b2a72420dbcd9b434ad.jpg) All formats and links are available at [https://hive.blog/@crrdlx/satoshi](https://hive.blog/@crrdlx/satoshi) ----

256260msg22119msg28729msg48171_msg22119_msg28729_

Kicking the Hornet's Nest - part 22 - the end

# Kicking the Hornet's Nest - third edition - part 22 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 506 - 527 (the end) ---- **Satoshi Nakamoto** <satoshin@gmx.com> Fri, Jan 7, 2011 at 1:00 PM To: Mike Hearn <mike@plan99.net> _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._ That's great! The first client-only implementation will really start to move things to the next step. Is it going to be open source, or Google proprietary? **Mike Hearn** <mike@plan99.net> Fri, Jan 7, 2011 at 1:24 PM To: Satoshi Nakamoto <satoshin@gmx.com> > That's great! The first client-only implementation will really start to > move things to the next step. Is it going to be open source, or Google > proprietary? _Open source. It has to be - I am developing it as a personal project in my spare time and Googles policy is that this is only allowed if you open source the results. But I would have done that anyway. I managed to spend my first coins on the testnet with my app a few days ago, hopefully will get another chance to make progress this weekend. Probably will have something to show publically sometime in Feb, touch wood._ **Satoshi Nakamoto** <satoshin@gmx.com> Mon, Jan 10, 2011 at 4:34 PM To: Mike Hearn <mike@plan99.net> Open source. Perfect. Once your code shows how to simplify it down, other authors can follow your lead. Client is a less daunting challenge than full implementation. If it's within reach of more developers, they'll come up with more polished UI and other things I didn't think of. I expect the original software will become the industrial old thing used by GPU farms and pool servers. BTW, later a good feature for a client version is to keep your private keys encrypted and you give your password each time you send. _I managed to spend my first coins on the testnet with my app a few days ago, hopefully will get another chance to make progress this weekend. Probably will have something to show publically sometime in Feb, touch wood._ Great, keep me updated. _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._ It works out to an even 10 minutes per block: 21000000 / (50 BTC * 24hrs * 365days * 4years * 2) = 5.99 blocks/hour I fudged it to 364.58333 days/year. The halving of 50 BTC to 25 BTC is after 210000 blocks or around 3.9954 years, which is approximate anyway based on the retargeting mechanism's best effort. I thought about 100 BTC and 42 million, but 42 million seemed high. I wanted typical amounts to be in a familiar range. If you're tossing around 100000 units, it doesn't feel scarce. The brain is better able to work with numbers from 0.01 to 1000. If it gets really big, the decimal can move two places and cents become the new coins. **Mike Hearn** <mike@plan99.net> Mon, Jan 10, 2011 at 4:48 PM To: Satoshi Nakamoto <satoshin@gmx.com> _Ah, of course, that makes sense._ _By the way, if you didn't see it already, there's a discussion on the security of secp256k1 on the forum:_ [_http://www.bitcoin.org/smf/index.php?topic=2699.0_](http://www.bitcoin.org/smf/index.php?topic=2699.0) _Hal (i presume this is Hal Finney) seems to think the curve is at higher risk of attack than random curves. I guess you chose secp256k1 for the mentioned performance improvement?_ _[Quoted text hidden]_ **Satoshi Nakamoto** <satoshin@gmx.com> Mon, Jan 10, 2011 at 8:47 PM To: Mike Hearn <mike@plan99.net> _By the way, if you didn't see it already, there's a discussion on the security of secp256k1 on the forum: _[_http://www.bitcoin.org/smf/index.php?topic=2699.0_](http://www.bitcoin.org/smf/index.php?topic=2699.0)_ Hal (i presume this is Hal Finney)_ Yes, it's him. He was supportive on the Cryptography list and ran one of the first nodes. _seems to think the curve is at higher risk of attack than random curves. I guess you chose secp256k1 for the mentioned performance improvement?_ I must admit, this project was 2 years of development before release, and I could only spend so much time on each of the many issues. I found guidance on the recommended size for SHA and RSA, but nothing on ECDSA which was relatively new. I took the recommended key size for RSA and converted to equivalent key size for ECDSA, but then increased it so the whole app could be said to be 256-bit security. I didn't find anything to recommend a curve type so I just... picked one. Hopefully there is enough key size to make up for any deficiency. At the time, I was concerned whether the bandwidth and storage sizes would be practical even with ECDSA. RSA's huge keys were out of the question. Storage and bandwidth seemed tighter back then. I felt the size was either only just becoming practical, or would be soon. When I presented it, I was surprised nobody else was concerned about size, though I was also surprised how many issues they argued, and more surprised that every single one was something I had thought of and solved. As it turns out, ECDSA verification time may be the greater bottleneck. (In my tests, OpenSSL was taking 3.5ms per ECDSA verify, or about 285 verifies per second) Client versions bypass the problem. As things have evolved, the number of people who need to run full nodes is less than I originally imagined. The network would be fine with a small number of nodes if processing load becomes heavy. **Martii Malmi (AKA Sirius) “COPA trial” email #256** **Date: Tue, 25 Jan 2011 18:34:03 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Fwd: Bitcoin question** **To: mmalmi@cc.hut.fi** The paper was published in 2008. Someone needs to correct Wikipedia; it incorrectly says the paper was published in 2009. The paper was released earlier than the software. _mmalmi@cc.hut.fi wrote:_ _> Can you comment on this?_ _>_ _> ----- Forwarded message from cjwells_1@yahoo.com -----_ _> Date: Mon, 24 Jan 2011 00:32:48 -0800 (PST)_ _> From: "Constance J. Wells" <cjwells_1@yahoo.com>_ _> Reply-To: "Constance J. Wells" <cjwells_1@yahoo.com>_ _> Subject: Re:_ _> To: mmalmi@cc.hut.fi_ _>_ _> Martti,_ _> Thank you for the pdf. It looks great. I do not see a date on it. When_ _> was it written?_ _>_ _> Mr. Mark Herpel of Digital Gold Currency Magazine brought Bitcoin to my_ _> attention for inclusion in my thesis. The thesis working title is:_ _> Digital Currency Systems: Emerging B2B e-Commerce Alternative During_ _> Monetary Crisis in the United States. I discuss the five types of_ _> systems per Mr. Herpels suggestion._ _>_ _> Appreciate it and hope to talk soon._ _>_ _> C._ _>_ _> Constance J. Wells, CeM, PMP: PMI certified_ _> Denver, CO U.S.A._ _> 303-730-6609_ _>_ _> --- On Mon, 1/24/11, mmalmi@cc.hut.fi <mmalmi@cc.hut.fi> wrote:_ _>_ _> From: mmalmi@cc.hut.fi <mmalmi@cc.hut.fi>_ _> Subject: Re:_ _> To: "Constance J. Wells" <cjwells_1@yahoo.com>_ _> Date: Monday, January 24, 2011, 1:22 AM_ _>_ _> Hi Constance,_ _>_ _> Thanks for your interest in Bitcoin, feel free to cite. There's also_ _> Satoshi Nakamoto's paper available at http://www.bitcoin.org/bitcoin.pdf_ _> if you want something with a more formal touch. Please let us know when_ _> your thesis is finished!_ _>_ _>_ _> -Martti_ _>_ _>> Martti Malmi_ _>> Currently I am a full time student at-_ _>> http://info.aspen.edu/_ _>> Aspen University, in Denver, CO, 303-333-4224._ _>> Masters of Science in Technology and Innovation._ _>>_ _>> I am writing my Thesis under the subject heading, digital currency_ _>> systems. May I cite your site in my Thesis?_ _>>_ _>> Thank you._ _>> Constance_ _>> Constance J. Wells, CeM, PMP: PMI certified_ _>> Denver, CO U.S.A._ _>> 303-730-6609_ _>>_ **Martii Malmi (AKA Sirius) “COPA trial” email #260** **Date: Tue, 22 Feb 2011 19:49:19 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: 0.3.20 release : shipped** **To: Gavin Andresen <gavinandresen@gmail.com>, Martti Malmi <mmalmi@cc.hut.fi>** _> I have not sent a message to the sourceforge bitcoin-list mailing list_ _> because I don't think I have permission; Satoshi, can you give me_ _> permission, encrypt the mailman password with my public key and send_ _> it to me, or just post the announcement?_ Martti should give you the Drupal admin password. Any subscriber can post to bitcoin-list. Here's the admin password in case you need it later. Gavin: -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.7 (MingW32) - WinPT 1.2.0 hQIOAxfAPINgyySWEAf9GHyuMqxkhoBe96hbHoFPIR4ORpMS/v2mpCT70UmgTt46 GVO5MeEOFE4JUqltYUaAE2u7e7+BbyNFeNk4o0kwJIWUXbRoBHj59vx+yzmeRLd9 YxTWxZA2zOVcYcYoDkiYAatwlQWQefzwYFcCnBSSsY1F9XLHMtLqNadhftOregoE 5Prhjk4ScAEOAmJ2CfYvWLD6FPAe4s6nXzP656oQghMgUivYoowHAjGUSvd8f1Qb fkV0isGIYCpHCOSZDZpysPCm63ibEeiuylvkT7Ayj2HoonqypFdv05mtyS7Jtq6a s06UqjLSyICoGJVk4x5HZhusgmbqViLvb6gM+iadbQf/U9KEKA5KyF0JvjYlx97k Bm7WpBIxKnP6Migl/Otol85EYt9rWN0lozLGw5Ko1JTZzXv3RrTsJafUYnDyAvtR 20JExoG84LatTeFiTqVWHiWZbYG2ECJHTO6jOmITvNvq/OgCID4hQvjvNQiXghae qzolzmZVEwDGAybWJoSvAsXjDWbAyHt9WJztHPgVRxgTBrnhoLAX0FwKGTCr7L/t emVEUqgEf3WqmljD+cCXSNVloQxGmPvaSsbITIZvX/emwq4MAC+SuRmJLJp6kSmu UhkxZMipvYHfyBPXoonAM7oYXNIaFQryS66UlEziSUevvU8TXiZMeUyyiMirOBXC itKhAedpc7NQYG+/KohTS0U9QfdygBfE2o6M96tRKFdMmbQz3Gyq0BaBpp98+ve+ VOVp90mYv9zq43G7tHnZektEjGzplHj0HzWhfbiy2dBrDGhkByYN4G6kX0JvU4ZX /ixmbOf5qZPqcgmz7fYDxKnkUQVumoEIfNXrUlAPcI2Ql9TnY0NIg9ZIVOGeT4lE 80kYloQVdCdnrJ7yLWexO0W1kSs= =S7eV -----END PGP MESSAGE----- Martti: -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.7 (MingW32) - WinPT 1.2.0 hQEMA+kEt/4bukJEAQgAlt5/Ks5pZPeusK0yefyMn7BqIVcOVHDaXbnf4dLKqq5J 6bKyMlkyYjhm1itZabi+IaV9k+1r7Wo50qOqfZNCSmG63hX3asXWd7QxThj4KDxr fvuUfiduf2AyZcB4r/baw1hsdC3VGxQutU0ookuJqfvCIse77clS2WimKJ5hrh5G KVdGApk3TxbILknalIs3mUw81sL0nvbO/aNrHiiNj44YU3Ehf5CieEJInHeYGTsJ AABLZcH6B7nymA8D4nrAAnDcjcSE8+iWMOtzI2duCHKtA+LVJOsg8n/zHqK9SZNF w+Xud7mBi/ZvnFGwCZh7cqJ/jZhNLLTQHiLr8M+i7dKhAekFho8aarOV9V4Cp2hT a8bQdbgwsednyjCzaq+C8xU+aYJcAV95qK6QG2hlT8xpDU2KHBHWIjDmPKlzgvKb 8/dQo5VDvtQkdyvrd9pMJeOUxFKEVW5ph+4LzKjKEWE1kJhzAwbxQMNKkXLzZJIa hJMNAVHDjnYcuI8EgJT+TjH2Kx+KwHX/OEOFaDXGP7XwMOuVZTVtbXnsJ24SFa1i m4U= =0TBL -----END PGP MESSAGE----- **Open sourced my Java SPV impl** 10 messages **Mike Hearn** <mike@plan99.net> Mon, Mar 7, 2011 at 2:13 PM To: Satoshi Nakamoto <satoshin@gmx.com> _Hi Satoshi, I hope you are doing well. I finally got all the lawyers happy enough to release BitCoinJ under the Google name using the Apache 2 license: _[_http://www.bitcoin.org/smf/index.php?topic=4236.0_](http://www.bitcoin.org/smf/index.php?topic=4236.0)_ It's incomplete - notably it doesn't properly handle block chain splits yet - but the rest is coming. I put a lot of work into documentation and comments so hopefully it'll open up BitCoin to a new audience who weren't able to understand/build the current code. Over the next month or two I'll be finishing off some of the bigger missing pieces for a full client-mode implementation. I know you are busy right now but I'm hoping you can find time to answer a few questions I had. As part of doing full SPV I'm thinking of adding a getmerklebranch message to the protocol. This would return a set of {blockhash, branch} pairs given tx hashes, so allowing verification of a broadcast transaction before it was incorporated into a block without storing the full chain. Does that approach sound good to you? Also, I've been thinking of exploring different transaction types lately, eg by removing the IsStandard() checks for the testnet. It's clear you put a lot of thought into transactions beyond simply moving coins around up front, but unfortunately none of it was in the paper or documented in the code. Escrow, multi-pay and so on are all interesting but I was wondering if you could compile a list of ideas for things we can do with the scripting language at some point. Finally, the code that allows for transaction replacement has been disabled but the comment doesn't say why. Is this just to reduce the attack surface/complexity or is there a deeper reason? I haven't fully understood why sequence numbers are a property of the tx inputs rather than the tx itself. Hope you can find the time/energy to rejoin us soon! I don't know if you've seen this: _[_http://bitcoin.sipa.be/speed-lin.png_](http://bitcoin.sipa.be/speed-lin.png)_ but it's exciting times for the network! thanks! __/mike_ **Satoshi Nakamoto** <satoshin@gmx.com> Wed, Mar 9, 2011 at 5:15 PM To: Mike Hearn <mike@plan99.net> _I hope you are doing well. I finally got all the lawyers happy enough to release BitCoinJ under the Google name using the Apache 2 license: It's incomplete - notably it doesn't properly handle block chain splits yet - but the rest is coming. I put a lot of work into documentation and comments so hopefully it'll open up BitCoin to a new audience who weren't able to understand/build the current code. Over the next month or two I'll be finishing off some of the bigger missing pieces for a full client-mode implementation._ That's great news! Much complexity can be left behind in a clean rewrite with only client requirements, and it opens it to Java developers too. _I know you are busy right now but I'm hoping you can find time to answer a few questions I had._ I'm happy to answer any questions. _As part of doing full SPV I'm thinking of adding a getmerklebranch message to the protocol. This would return a set of {blockhash, branch} pairs_ That's a CMerkleTx _given tx hashes, so allowing verification of a broadcast transaction before it was incorporated into a block without storing the full chain. Does that approach sound good to you?_ I don't understand. A merkle branch links a tx back to a block, which only has significance if the block exhibits proof-of-work. Linking back to an as-yet unsolved block proves nothing. Network nodes are able to verify 0-conf txes because they have the complete tx index, so they can: 1) verify signatures against dependencies. 2) say that they haven't seen another spend yet, because they know about every tx in existence. Are you talking about CMerkleTxes for the tx's dependencies? That would get part 1), but not part 2). If you don't know about all txes in existence, I don't know how to do 2). You could only rely on trusting other nodes for that. That trust can be distributed over multiple nodes. Nodes only relay transactions they accept as valid. If you receive inv messages for a tx from all the nodes you're connected to, they're attesting that it's valid and the first spend they saw. _Also, I've been thinking of exploring different transaction types lately, eg by removing the IsStandard() checks for the testnet._ Very good idea. That should definitely be allowed on -testnet. _It's clear you put a lot of thought into transactions beyond simply moving coins around up front, but unfortunately none of it was in the paper or documented in the code. Escrow, multi-pay and so on are all interesting but I was wondering if you could compile a list of ideas for things we can do with the scripting language at some point. Finally, the code that allows for transaction replacement has been disabled but the comment doesn't say why. Is this just to reduce the attack surface/complexity or is there a deeper reason?_ Just to reduce surface area. It wouldn't help with increasing tx fee. A tx starts being valid at nLockTime. It wouldn't work to have a tx that stops being valid at a certain time; once a tx ever becomes valid, it must stay valid permanently. See these threads: [http://www.bitcoin.org/smf/index.php?topic=1786.msg22119#msg22119](/home/crrdlx/Dropbox/My%20Docs/books/kicking%20hornets%20nest%20-%20complete%20writings%20of%20satoshi%20nakamoto/edition3_files/_blank) [http://www.bitcoin.org/smf/index.php?topic=2181.msg28729#msg28729](/home/crrdlx/Dropbox/My%20Docs/books/kicking%20hornets%20nest%20-%20complete%20writings%20of%20satoshi%20nakamoto/edition3_files/_blank) _I haven't fully understood why sequence numbers are a property of the tx inputs rather than the tx itself._ It's for contracts. An unrecorded open transaction can keep being replaced until nLockTime. It may contain payments by multiple parties. Each input owner signs their input. For a new version to be written, each must sign a higher sequence number (see IsNewerThan). By signing, an input owner says "I agree to put my money in, if everyone puts their money in and the outputs are this." There are other options in SignatureHash such as SIGHASH_SINGLE which means "I agree, as long as this one output (i.e. mine) is what I want, I don't care what you do with the other outputs.". If that's written with a high nSequenceNumber, the party can bow out of the negotiation except for that one stipulation, or sign SIGHASH_NONE and bow out completely. The parties could create a pre-agreed default option by creating a higher nSequenceNumber tx using OP_CHECKMULTISIG that requires a subset of parties to sign to complete the signature. The parties hold this tx in reserve and if need be, pass it around until it has enough signatures. One use of nLockTime is high frequency trades between a set of parties. They can keep updating a tx by unanimous agreement. The party giving money would be the first to sign the next version. If one party stops agreeing to changes, then the last state will be recorded at nLockTime. If desired, a default transaction can be prepared after each version so n-1 parties can push an unresponsive party out. Intermediate transactions do not need to be broadcast. Only the final outcome gets recorded by the network. Just before nLockTime, the parties and a few witness nodes broadcast the highest sequence tx they saw. **Mike Hearn** <mike@plan99.net> Wed, Mar 9, 2011 at 5:39 PM To: Satoshi Nakamoto <satoshin@gmx.com> If you don't know about all txes in existence, I don't know how to do 2). You could only rely on trusting other nodes for that. That trust can be distributed over multiple nodes. Nodes only relay transactions they accept as valid. If you receive inv messages for a tx from all the nodes you're connected to, they're attesting that it's valid and the first spend they saw. _Good point. I was talking about verifying the inputs yes, but it is indeed pointless unless you hear about all open transactions as well. So being able to fetch a CMerkleTx is not important._ Just to reduce surface area. It wouldn't help with increasing tx fee. A tx starts being valid at nLockTime. It wouldn't work to have a tx that stops being valid at a certain time; once a tx ever becomes valid, it must stay valid permanently. See these threads: [http://www.bitcoin.org/smf/index.php?topic=1786.msg22119#msg22119](/home/crrdlx/Dropbox/My%20Docs/books/kicking%20hornets%20nest%20-%20complete%20writings%20of%20satoshi%20nakamoto/edition3_files/_blank) [http://www.bitcoin.org/smf/index.php?topic=2181.msg28729#msg28729](/home/crrdlx/Dropbox/My%20Docs/books/kicking%20hornets%20nest%20-%20complete%20writings%20of%20satoshi%20nakamoto/edition3_files/_blank) _I see. So right now fees are tricky because you have to decide up front what the fee should be, and if you guess too low, there's no way to correct the transaction and though the network will eventually forget it, your wallet still records that you spent the coins. This has already started happening._ _It's for contracts._ _Ah ha. A whole unexplored area of the system opens up before my eyes :-) The concept of forming distributed contracts and escrow transactions without needing to trust an intermediary is a concept nearly as novel as BitCoin itself, I think._ _I have more questions!_ _There's an unfinished part of the protocol that deals with setting up publisher/subscriber channels for distributed routing via the network. What was the purpose of this? Was the idea to have a p2p market or did it have some kind of lower level function, like perhaps broadcasting expected tx fees?_ _There was an interesting discussion of generalizing BitCoin some months ago, but we struggled to fully understand how you planned to achieve it. I think I understood the concept of placing another merkle tree on top of multiple separate chains:_ [_http://www.bitcoin.org/smf/index.php?topic=3414.msg48171#msg48171_](/home/crrdlx/Dropbox/My%20Docs/books/kicking%20hornets%20nest%20-%20complete%20writings%20of%20satoshi%20nakamoto/edition3_files/_blank) _But I didn't understand your comment about having 200 bytes for backwards compatibility. Also, I guess this is obvious, but to be super clear - in your idea the alternative chains would share exactly the same format and sets of verification rules as BitCoin (the same script language etc), so all miners can verify all blocks even if they are non-financial in nature? And then the point of having separate block chains is simply to manage storage costs and bandwidth for client-mode implementations?_ _Thanks!_ **Satoshi Nakamoto** <satoshin@gmx.com> Wed, Mar 9, 2011 at 7:39 PM To: Mike Hearn <mike@plan99.net> _See these threads: _[_http://www.bitcoin.org/smf/index.php?topic=1786.msg22119#msg22119_](/home/crrdlx/Dropbox/My%20Docs/books/kicking%20hornets%20nest%20-%20complete%20writings%20of%20satoshi%20nakamoto/edition3_files/_blank)[_http://www.bitcoin.org/smf/index.php?topic=2181.msg28729#msg28729_](/home/crrdlx/Dropbox/My%20Docs/books/kicking%20hornets%20nest%20-%20complete%20writings%20of%20satoshi%20nakamoto/edition3_files/_blank)_ I see. So right now fees are tricky because you have to decide up front what the fee should be, and if you guess too low, there's no way to correct the transaction and though the network will eventually forget it, your wallet still records that you spent the coins. This has already started happening._ The network won't forget, and the owner's client will keep rebroadcasting it. The overflow transaction was remembered by the network for several months even as the remaining 0.3.8 nodes diminished. Priority includes age, so as a transaction waits it ages and will eventually have enough priority. See one of the links above where I contemplate sending an honest double-spend to increase the fee. It's a lot of work but could be done. I don't think it's worth it right now. The current system, where nodes make sure to include enough fee for current conditions and the network makes sure all transactions get processed eventually, works well enough. Gavin is fixing the oversight where nodes didn't check the priority of their own transactions when writing them. Users still worried about processing speed uncertainty should think of it as encouragement to include a fee. _There's an unfinished part of the protocol that deals with setting up publisher/subscriber channels for distributed routing via the network. What was the purpose of this? Was the idea to have a p2p market or did it have some kind of lower level function, like perhaps broadcasting expected tx fees?_ I was trying to implement an eBay style marketplace built in to the client. Publish/subscribe would be used for broadcasting product offers and ratings/reviews. Your reviews would be weighted by the blocks you've generated. I rightly abandoned it in favour of JSON-RPC, so other authors could implement it externally. The publish/subscribe "meet in the middle" mechanism was an interesting concept, but nothing remains that uses it. It was part of writing code to explore the most technically demanding use cases and make sure Bitcoin could support everything that might be needed in the future, given the locked-in nature of the rules once the block chain started. _There was an interesting discussion of generalizing BitCoin some months ago, but we struggled to fully understand how you planned to achieve it. I think I understood the concept of placing another merkle tree on top of multiple separate chains: _[_http://www.bitcoin.org/smf/index.php?topic=3414.msg48171#msg48171_](/home/crrdlx/Dropbox/My%20Docs/books/kicking%20hornets%20nest%20-%20complete%20writings%20of%20satoshi%20nakamoto/edition3_files/_blank)_ But I didn't understand your comment about having 200 bytes for backwards compatibility. Also, I guess this is obvious, but to be super clear - in your idea the alternative chains would share exactly the same format and sets of verification rules as BitCoin (the same script language etc), so all miners can verify all blocks even if they are non-financial in nature? And then the point of having separate block chains is simply to manage storage costs and bandwidth for client-mode implementations?_ No, other chains do not follow Bitcoin's rules. They are completely independent chains. They share nothing except the miners. The other network's definition of proof-of-work is to make a solved (according to their own chain's difficulty) Bitcoin-format block that has a hash of their own block in it. They don't care if the Bitcoin block is valid or used by Bitcoin, but it allows miners to work both chains at once. Procedure to hash a BitDNS block: - hash the BitDNS block - construct a Bitcoin block - insert the BitDNS hash into the scriptSig of tx 0 in the Bitcoin block - hash the Bitcoin block The BitDNS block is valid if that hash is below BitDNS's target. The BitDNS block needs to have with it about 200 bytes of data needed to reconstruct the Bitcoin block used in the hash: - the Bitcoin block header - the merkle branch to tx 0 - tx 0 (btw, tx 0's prev hash is always 0 so leaving that out saves 32 bytes) Note that it doesn't matter if the fodder "Bitcoin block" was actually valid in the Bitcoin chain, though it could have been. To BitDNS, it's just a bunch of salt necessary to do its convoluted hash calculation. If a miner is only mining for BitDNS and doesn't care about Bitcoin, it would use a blank Bitcoin block of all zeroes (except the nonce). To further expand the idea for extensibility, consider instead of putting the BitDNS block hash in tx 0, you put the root of a merkle tree that includes BitDNS. This is the merkle tree that is conceptually at the top. **Mike Hearn** <mike@plan99.net> Wed, Mar 9, 2011 at 7:52 PM To: Satoshi Nakamoto <satoshin@gmx.com> _Thanks again._ _Hal speculated that you intended to stash the new merkle root in the tx0 scriptSig. Good to know at least he had the right idea :-)_ **Holding coins in an unspendable state for a rolling time window** 6 messages **Mike Hearn** <mike@plan99.net> Mon, Apr 18, 2011 at 11:14 PM To: Satoshi Nakamoto <satoshin@gmx.com> _Hello Satoshi, I hope this mail finds you well. Recently I've been thinking about how BitCoin can help handle internet abuse and would appreciate your thoughts. My "day job" is on the Google abuse team. We make extensive use of phone verification to control outbound spam from our network. Facebook and Craigslist do the same. Phone verification works well because phone numbers are something most people have access to at least one or two of, but rarely more. Yet it has significant downsides - it's expensive (for us), flaky, some people don't like the privacy implications, and some spam is profitable enough that buying lots of SIM cards is worth it. It would be ideal if BitCoins could be put up as collateral against an account. The amount put up would help determine the limits the system placed on your behavior (eg how much mail you can send), in an anonymous and private way. But how to implement this? Burning coins forever is easy, just set the only output to be <pubkey> OP_FALSE. Now you can sign some server-provided challenge with that key and prove you did indeed burn those coins. A key would only be usable with one account so spammers cannot simply put up a huge collateral and then resell signatures generated with that key. If the account was found to be abused it'd be terminated like today, and the coins would be "gone". But people do come and go from these big networks and the thought of losing the coins if you quit Google to run your own mail is unappealing. It would be ideal if coins could be locked up for a period of time such that they cannot be spent until time X, where X can be constantly pushed into the future if the owner desires it but otherwise the coins eventually become spendable again. To verify your Google account, you would take some amount of coins (say 10) and set it up so you cannot spend them for 6 months. The script language has no concept of time. OP_BLOCKNUMBER was ruled out because re-orgs could potentially invalidate entire chains of transactions. But is an OP_DAY feasible? I'm thinking of an opcode that returns the timestamp from the block header, but rounded to the nearest day to handle the natural clock drift seen in the block chain. If it could work then a TX that ties up coins until past a certain day is easy to construct. Updating it so the deadline is constantly moving is harder. A simple brute force solution is to require the user to put up 2x the coins such that at the point the first tx is about to expire and become spendable again, the second tx is created. In this way you always have at least one tx of sufficiently distant deadline to act as collateral. But this is inelegant. A better way would be to introduce a new rule allowing a tx to connect to such an output before the deadline has passed, as long as the output of that tx is once again a deadlined output of the same form. However this is less general than the scripting language so is also somewhat inelegant. What do you think?_ **Satoshi Nakamoto** <satoshin@gmx.com> Wed, Apr 20, 2011 at 11:39 AM To: Mike Hearn <mike@plan99.net> If the script language is not stateless, if it has access to any outside information that changes or varies between nodes, attackers can use it to fork the chain. The only exception is if it is always false before a certain time and permanently true after, which is implemented with nLockTime. Since Google is trusted, couldn't users pay a token deposit to Google and Google pays them back when they close the account? To answer your question though, yes it can be done without using trust: Tx 1 from User pays to a script that requires the signature of both Google and User to spend. Tx 2 (the contract) spends Tx 1 and pays it to User. nLockTime is the time to release the money. Steps: 1) Google gives User a pubkey to use in creating Tx 1. 2) User privately creates Tx 1, does not broadcast it yet. 3) User gives the hash of Tx 1 to Google. 4) Google signs its part of Tx 2, with nLockTime set, and gives it to User. 5) User broadcasts Tx 1. 6) User signs his half of Tx 2 and broadcasts it. With these steps, the user already has Google's signed half of Tx 2 in hand before he broadcasts Tx 1, so he is assured of what bargain he is signing the money to. This is the general pattern for safely signing contracts. Tx 2 is prepared first so the parties know what they're paying into. Tx 1 is broadcast to lock up the money and assign it to Tx 2. In other words, all parties assign their money to a pool that is controlled by the unanimous agreement of the group, but first the group has already signed agreement for the default action to take with the money, or partially signed multiple available options that a party can complete by adding the last signature. By mutual agreement, the parties can always write another version of Tx 2 that releases the money immediately. [Quoted text hidden] **Mike Hearn** <mike@plan99.net> Wed, Apr 20, 2011 at 1:55 PM To: Satoshi Nakamoto <satoshin@gmx.com> _Thanks, that's helpful. I'm understanding contracts better now._ _So the issue with having an OP_TIME/OP_BLOCKNUMBER opcode is not only that the results can change after a re-org (you said that previously), but also that people could use it to produce transactions that cease to be valid entirely after a certain time and cause a fork. Kind of obvious in hindsight._ _Since Google is trusted, couldn't users pay a token deposit to Google and Google pays them back when they close the account?_ _Google and trust is a complicated issue. Lots of people use our services despite having little trust in us. Some people start out trusting us but then read (often sensationalist or wrong) stories in the media that change their minds, and so on. This is one of the problems we have with phone verification ... a few people don't want to give us their phone number._ _For this case it'd probably be OK because trust around data privacy is different to trust around obeying contracts. I'm sure nobody would doubt that Google will pay them back - I bet we'd have an even better credit rating than the US Government in that sense :-) But we have quite a high rate of false positives with our verifications and some people would suspect we were accidentally verifying users in order to accumulate big piles of coins with which to earn interest. I've seen much sillier conspiracy theories gain traction._ _Besides, avoiding the need to trust big, complex institutions is much more BitCoin-ish. And I correctly suspected there was a way to do it I didn't understand yet so it's a good chance to learn more about BitCoin._ _To answer your question though, yes it can be done without using trust_ _If I wrote a wiki page on how to build contracts with BitCoin, would you mind reviewing it?_ _I'm thinking it might be a good idea to re-enable transaction replacement soon because as the network grows, it will become harder and harder to upgrade. In one sense this is good as it makes it hard to change the fundamental rules of the system. On the other hand, we risk having a protocol which has many unused features because they aren't widely supported enough. HTTP suffered this fate with many of its verbs as well as features like pipelining._ _Did you have any list of tasks for re-activation, some kind of audit or finishing off some code?_ _I had a few other things on my mind (as always). One is, are you planning on rejoining the community at some point (eg for code reviews), or is your plan to permanently step back from the limelight? One reason I'm peppering you with questions is I worry that much of BitCoins potential lies in careful use of currently inactive features, but there's little guidance on how to do it. And frankly, I don't think I'm smart enough to figure it all out on my own. Maybe theymos is, he seems to understand it well. But if one day you leave entirely, parts of the protocol might fall into disuse, which would be a shame._ _Another is the economics of mining after the transition to a fully fee based system. Right now difficulty is roughly a function of the USD/BTC exchange rate and per-block inflation. When mining reward is set by the market, it might be possible for a "Tragedy of the commons" to occur in which everyone benefits from a high difficulty, but nobody specifically wants to pay fees to get it. Besides, valuing difficulty is quite hard as you never know what the capabilities of attackers are until it's too late. Would it be possible for fees to trend towards zero over time as some miner is always willing to accept cheaper transactions and as miners drop out, the difficulty adjusts so the delays never get too bad to tolerate?_ _As always thanks for your insights._ **Satoshi Nakamoto** <satoshin@gmx.com> Sat, Apr 23, 2011 at 3:40 PM To: Mike Hearn <mike@plan99.net> _I had a few other things on my mind (as always). One is, are you planning on rejoining the community at some point (eg for code reviews), or is your plan to permanently step back from the limelight?_ I've moved on to other things. It's in good hands with Gavin and everyone. I do hope your BitcoinJ continues to be developed into an alternative client. It gives Java devs something to work on, and it's easier with a simpler foundation that doesn't have to do everything. It'll get critical mass when impatient new users can get started using it while the other one is still downloading the block chain. ##### P2P Foundation #### Bitcoin open source implementation of P2P currency ##### _2014-03-07 01:17:00 UTC_ - [-](http://p2pfoundation.ning.com/xn/detail/2003008:Comment:52186) I am not Dorian Nakamoto. _Editor’s note: this comment was apparently made in response to a March 6, 2014 Newsweek article that Dorian Nakamoto was the real Satoshi Nakamoto of Bitcoin fame. The post is debated as to its authenticity. Some say that Satoshi’s account was hacked and that this was not actually written by Satoshi Nakamoto._ Kicking the Hornet’s Nest: The Complete Writings, Emails, and Forum Posts of Satoshi Nakamoto, the Founder of Bitcoin and Cryptocurrency ![](file:///tmp/lu30467eu8.tmp/lu30468zxe_tmp_8b9f10358af85d85.png) All formats and links are available at [https://hive.blog/@crrdlx/satoshi](https://hive.blog/@crrdlx/satoshi) ----

256260msg22119msg28729msg48171_msg22119_msg28729_

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](nostr:nprofile1qyv8wumn8ghj7mn0wdj8y6tkv5hxzurs9aex2mrp0yq3wamnwvaz7tmjv4kxz7fwwpexjmtpdshxuet59uqzqqzmcn0yrn7ttq8hrjkk46ysn2tk26rr8f8k4y7xkl74hlh3rcdzm9d3t8), 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](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(); CRITICAL_BLOCK(cs_mapTransactions) @@ -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() > MAX_BLOCK_SIZE || ::GetSerializeSize(*this, SER_NETWORK) > MAX_BLOCK_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() > MAX_BLOCK_SIZE || ::GetSerializeSize(*this, SER_NETWORK) > MAX_BLOCK_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) CRITICAL_BLOCK(cs_vNodes) 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); } [![](file:///tmp/lu30467eu8.tmp/lu30468vgb_tmp_96a26dbee451013d.gif)](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. ----

241msg26999msg26876243245msg28228msg28292msg28302247msg28313msg28301msg28533msg27173msg28549msg28434msg28640msg28330msg28572msg28643msg28696msg28715msg28700msg28729msg28917msg28947msg28959msg28938msg28963msg29159msg29130msg29165msg29095msg29124msg29259msg29223msg29280msg29479249251msg30043_254