#

msg22119

(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 20

# Kicking the Hornet's Nest - third edition - part 20 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 450 - 475 ---- ##### BitcoinTalk #### Re: Memory leak ##### _2010-10-03 22:07:00 UTC_ - [-](https://bitcointalk.org/index.php?topic=1023.msg15150#msg15150) You're connecting to yourself. All 21 connection attempts were to a node with version 31300 (0.3.13). Not everyone has 0.3.13 yet. IRC seems to be working. It ought to have other nodes to try. There may be something I need to do to make sure it doesn't try to connect to itself again right away after disconnecting. I can't see how it's happening though, it should be resetting nLastTry which would put it to the back of the queue, but the log doesn't show it. You can try moving addr.dat aside. Maybe there's something wrong in it. Are you using -addnode? ##### BitcoinTalk #### Re: Version 0.3.13, please upgrade ##### _2010-10-03 23:46:19 UTC_ - [-](https://bitcointalk.org/index.php?topic=1327.msg15167#msg15167) Make sure you keep your node online so it'll keep rebroadcasting transaction b412a0. It haven't seen it rebroadcast since 29/09/2010 16:41. ##### BitcoinTalk #### Re: Website and software translations ##### _2010-10-04 01:44:41 UTC_ - [-](https://bitcointalk.org/index.php?topic=151.msg15176#msg15176) Thanks eurekafag, Russian translation added to SVN rev 160. ##### BitcoinTalk #### Re: Website and software translations ##### _2010-10-04 19:21:01 UTC_ - [-](https://bitcointalk.org/index.php?topic=151.msg15360#msg15360) [**Quote from: eurekafag on October 04, 2010, 10:55:56 AM**](https://bitcointalk.org/index.php?topic=151.msg15248#msg15248) Where can I find the latest English .po file to keep the translation up-to-date? poedit does it. Either get the src directory from a release, or download it with SVN. Place your .po file 3 directories deep under the src directory. Open it with poedit and do Catalog->Update from sources. So for example, you have: src srcase58.h srcignum.h ... src\util.cpp src\util.h src\xpm src\locale u\LC_MESSAGESitcoin.po Open bitcoin.po with poedit, do Catalog->Update from sources. It looks for the sourcecode up 3 directories (..\..\..) from where bitcoin.po is. This updates your existing .po file you already worked on and adds any news strings. It may try to match close strings, so check things over and make sure it didn't make any bad guesses. Make sure you use the .po file I uploaded to SVN or in a release, because I always fix up at least a few things. I'm attaching your Russian one to this message. ##### BitcoinTalk #### Re: [PATCH] increase block size limit ##### _2010-10-04 19:48:40 UTC_ - [-](https://bitcointalk.org/index.php?topic=1347.msg15366#msg15366) It can be phased in, like: if (blocknumber > 115000) maxblocksize = largerlimit It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete. When we're near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade. **Martii Malmi (AKA Sirius) “COPA trial” email #237** **Date: Mon, 04 Oct 2010 20:05:26 +0100** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: SMF php code** **To: mmalmi@cc.hut.fi** I reuploaded the changes. For future reference, the files in Sources with customisations are: Register.php PersonalMessage.php ManageRegistration.php Subs.php Let me know whenever you do an upgrade so I can make sure all my changes survived. Hopefully the 1.1.x line is mature and updates are infrequent. We shouldn't upgrade to 2.0. I made a ton of customisations that wouldn't be compatible, and I kind of prefer the look of 1.1 over 2.0 anyway. The captcha url has mycode=4 added to it, and the register page has extra hidden mycode=2 through 5 images so any automated thing wouldn't know which one to pick. Everything that uses captcha has to have that mycode=4 thing added. Something in sending personal messages also uses captcha. _mmalmi@cc.hut.fi wrote:_ _> Sorry, I didn't notice your custom code when updating. Re-integration is_ _> a good idea if it's not too much work. I've removed hundreds of spam_ _> accounts by making a search for old accounts that have a webpage url and_ _> 0 posts._ _>_ ##### BitcoinTalk #### Re: Website and software translations ##### _2010-10-06 15:42:39 UTC_ - [-](https://bitcointalk.org/index.php?topic=151.msg15660#msg15660) poedit reorganised the file for some reason. I re-ran update from sources and it put it back in the original order so it's fine now. Did you run it on a drive where files aren't sorted alphabetically, like a FAT drive or USB flash drive? Strings aren't added or changed very often. It's months before enough changes build up. I uploaded the changes. This Windows build has the Russian translation in it: [http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe](http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe) ##### BitcoinTalk #### Re: I broke my wallet, sends never confirm now. ##### _2010-10-06 16:54:23 UTC_ - [-](https://bitcointalk.org/index.php?topic=1306.msg15672#msg15672) That's going to be more of a SelectCoins thing. SVN rev 161 has a refinement to recursively determine if your own unconfirmed transactions can be spent. This is needed because you should be able to spend your own change right away. The new recursive determination is: 0/unconfirmed can be spent if it's yours and all its dependencies are either in a block or also yours. Here's a Windows build: [http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe](http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe) This version is an improvement if you already had a 0/unconfirmed transaction and might have already spent it. If you were the original creator of a 0/unconfirmed transaction, you still need theymos' patch instead. ##### BitcoinTalk #### Re: Tor connections not working reliably, many seednodes offline ##### _2010-10-06 17:36:41 UTC_ - [-](https://bitcointalk.org/index.php?topic=1375.msg15682#msg15682) Maybe you were just unlucky to have an exit node without reverse lookup. The IRC server's response doesn't look like it was disconnecting you for that. It's supposed to go IRC SENDING: NICK after that, and it doesn't so it gets timed out. I see the problem. The IRC code is looking for various phrases to see when the server is ready to receive your NICK, but it's not looking for that particular phrase. I'll fix it. I don't know if it's really required to wait for the server to finish looking up hostname before sending nick. How long did it take to get connected with TOR the first time, having to use the seed nodes? ##### BitcoinTalk #### Re: The Niche List ##### _2010-10-06 23:10:31 UTC_ - [-](https://bitcointalk.org/index.php?topic=1268.msg15741#msg15741) [_**Quote from: kiba on September 23, 2010, 04:00:16 PM**_](https://bitcointalk.org/index.php?topic=1268.msg13828#msg13828) _1. Download site like rapidshare and other crappy host. Inconvenient captcha and required paypal. Bitcoin can possibly take both roles and streamline the whole process._ Repeating myself here, but there is open source software for that, so it would just be a matter of bolting on a Bitcoin payment mechanism. One good one I found was Mihalism Multi Host. It's designed as a free host, so it would just need a few tweaks to loosen up restrictions consistent with paid use. ##### BitcoinTalk #### Key pool feature for safer wallet backup ##### _2010-10-09 20:19:33 UTC_ - [-](https://bitcointalk.org/index.php?topic=1414.msg16316#msg16316) SVN rev 163 (ver 0.3.13.3) has the key pool feature. Pre-generated new keys are aged in a queue before use, so that backups of wallet.dat hold keys you'll use in the future. For now I made the default pool size 100. It can be configured with -keypool=. Be aware, it takes a little time to increase the pool size, so don't go crazy with it. Disk space is about 1K per key. I have not addressed the recovery side of this yet. If you actually did restore an old wallet.dat, I think you may have to delete blk*.dat to rediscover your own transactions during the redownload. I've only tested this moderately. You might not want to use this for a website server until it's had some more testing. ##### BitcoinTalk #### Version 0.3.14 ##### _2010-10-21 16:39:27 UTC_ - [-](https://bitcointalk.org/index.php?topic=1528.msg17924#msg17924) Version 0.3.14 is now available [http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.14/](http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.14/) Changes: - Key pool feature for safer wallet backup Gavin Andresen: - TEST network mode with switch -testnet - Option to use SSL for JSON-RPC connections on unix/osx - validateaddress RPC command eurekafag: - Russian translation ##### BitcoinTalk #### Re: Website and software translations ##### _2010-10-21 22:50:47 UTC_ - [-](https://bitcointalk.org/index.php?topic=151.msg17965#msg17965) The order matters not to the program, but it matters to me maintaining it. If it jumbles the order of the .po file then I can't diff for changes. I have to update all 7 translation files when I change the English text in the program, and it's easier when they're all in the same order. I can still put it back into normal order by making poedit rescan it. It is normal that untranslated strings are shown on top. [_**Quote from: eurekafag on October 06, 2010, 07:39:36 PM**_](https://bitcointalk.org/index.php?topic=151.msg15697#msg15697) _By the way, there are some similar lines that possibly may be replaced by one. They are very close by meaning and differs only by 1-2 words. Just a suggestion of course._ I know, but not easily without complicating the sourcecode. ##### BitcoinTalk #### Re: ERROR - PLEASE HELP ME! ##### _2010-10-23 18:22:49 UTC_ - [-](https://bitcointalk.org/index.php?topic=1530.msg18241#msg18241) [_**Quote from: theymos on October 21, 2010, 10:00:26 PM**_](https://bitcointalk.org/index.php?topic=1530.msg17955#msg17955) _his block count remains "stuck" at 1698._ He was generating invalid blocks at difficulty 1.0. He must have a corrupted entry in his blk0001.dat or blkindex.dat file. He just needs to delete blk*.dat and let it redownload. The safety lockdown detected the problem and was displaying "WARNING: Displayed transactions may not be correct!" because it saw a longer chain existed that it was unable to accept. The safety lockdown cannot stop generation or it would create an attack possibility. [_**Quote from: gavinandresen on October 22, 2010, 02:25:14 PM**_](https://bitcointalk.org/index.php?topic=1530.msg18074#msg18074) _The Bitcoin client really shouldn't allow coin generation until you have all of the blocks up to the last block checkpoint._ Good idea, I made a change to make sure it won't generate before checkpoint block 74000. ##### BitcoinTalk #### Re: ERROR - PLEASE HELP ME! ##### _2010-10-23 18:38:04 UTC_ - [-](https://bitcointalk.org/index.php?topic=1530.msg18245#msg18245) OK, if it really won't get past block 1698 on redownload, then we're in stranger territory. Yes, possibly he has antivirus software or even a router or filewall that is pattern matching a sequence of bytes and censoring it. It would be instructive to get knightmb's blk*.dat and see if that gets him past that point. ##### BitcoinTalk #### Re: Win7 64bit since last patch Tues now crashes ##### _2010-10-23 18:52:02 UTC_ - [-](https://bitcointalk.org/index.php?topic=1540.msg18246#msg18246) [**Quote from: Odin on October 22, 2010, 09:24:38 PM**](https://bitcointalk.org/index.php?topic=1540.msg18105#msg18105) Fault Module Name: mingwm10.dll This is the important clue. I believe it's saying it crashed in that. Maybe there are other versions of it to try. mingwm10.dll is just a simple placeholder thing that satisfies some callback requirement for multithreaded apps. Is anyone else running OK on Windows 64-bit? ##### BitcoinTalk #### Re: Suggestion: Allow short messages to be sent together with bitcoins ? ##### _2010-10-23 19:02:57 UTC_ - [-](https://bitcointalk.org/index.php?topic=1545.msg18250#msg18250) ECDSA can't encrypt messages, only sign signatures. It would be unwise to have permanently recorded plaintext messages for everyone to see. It would be an accident waiting to happen. If there's going to be a message system, it should be a separate system parallel to the bitcoin network. Messages should not be recorded in the block chain. The messages could be signed with the bitcoin address keypairs to prove who they're from. ##### BitcoinTalk #### Re: Multiple Wallets, one computer ##### _2010-10-24 19:17:51 UTC_ - [-](https://bitcointalk.org/index.php?topic=665.msg18349#msg18349) I have the beginning of something like this. It's mostly like what Gavin described. Some more rpc interface: move <fromaccount> <toaccount> <amount> Move from one internal account to another. I think blank account name ("") will be your default account. If you sell something to a user, you could do move "theiraccount" "" 123.45. Is "move" the best name for this? I shied away from "transfer" because that sounds too close to sending a transaction. I'm thinking a new function getaccountaddress instead of overloading getnewaddress: getaccountaddress <account> Gives you an address allocated from getnewaddress <account>. It'll keep giving the same address until something is received on the address, then it allocates a new address. (It automatically does what the sample code I posted some time ago did) Would these commands make it possible in simple cases to implement your website without needing a database of your own? ##### BitcoinTalk #### Re: Multiple Wallets, one computer ##### _2010-10-25 16:53:53 UTC_ - [-](https://bitcointalk.org/index.php?topic=665.msg18508#msg18508) Here's some pseudocode of how you would use the account based commands. It sure makes website integration a lot easier. 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 out of their account move(username, "", amount, 6) // withdrawal sendfrom(username, bitcoinaddress, amount, 6) ##### BitcoinTalk #### Re: Win7 64bit since last patch Tues now crashes ##### _2010-10-25 17:27:47 UTC_ - [-](https://bitcointalk.org/index.php?topic=1540.msg18511#msg18511) The only thing I can think of is to see if there are other versions of mingwm10.dll you can get. mingwm10.dll is a tiny little DLL that came with the MinGW compiler that you need when you build for multi-thread. I don't know exactly what it does, but it probably just says something like "yes Windows, see I'm in a DLL like you insisted." The end of your debug.log file might show the last thing it was doing before it crashed. ##### BitcoinTalk #### Re: New icon/logo ##### _2010-11-13 00:55:51 UTC_ - [-](https://bitcointalk.org/index.php?topic=64.msg21766#msg21766) I'm happy if someone with artistic skill wants to contribute alternatives. The icon/logo was meant to be good as an icon at the 16x16 and 20x20 pixel sizes. I think it's the best program icon, but there's room for improvement at larger sizes for a graphic for use on websites. It'll be a lot simpler if authors could make their graphics public domain. ##### BitcoinTalk #### Re: Some testing that I did on the testnetwork, my findings. ##### _2010-11-13 23:25:26 UTC_ - [-](https://bitcointalk.org/index.php?topic=1668.msg21896#msg21896) Thank you for limiting flood tests to the testnet. Version 0.3.15 combines several features to help legitimate transactions jump the queue during a flood attack. The key was Gavin's idea for prioritising transactions based on the age of their dependencies. Every coin is entitled to turn over so often. The longer waited, the more priority accumulates. Priority is sum(valuein * age) / txsize. Transaction fee still takes precedence over priority, and priority determines the order of processing within a fee strata. In support of the priority feature, SelectCoins only uses your own 0 conf transactions only as a last resort if that's all you have left. This helps keep you from turning your coins over rapidly unless you're forcing it by actually turning all your coins over rapidly. ##### BitcoinTalk #### Version 0.3.15 ##### _2010-11-13 23:26:40 UTC_ - [-](https://bitcointalk.org/index.php?topic=1780.msg21897#msg21897) Version 0.3.15 is now available. Changes: - paytxfee switch is now per KB, so it adds the correct fee for large transactions - sending avoids using coins with less than 6 confirmations if it can - BitcoinMiner processes transactions in priority order based on age of dependencies - make sure generation doesn't start before block 74000 downloaded - bugfixes by Dean Gores - testnet, keypoololdest and paytxfee added to getinfo ##### BitcoinTalk #### Re: Some testing that I did on the testnetwork, my findings. ##### _2010-11-14 16:53:19 UTC_ - [-](https://bitcointalk.org/index.php?topic=1668.msg21959#msg21959) [_**Quote from: ByteCoin on November 13, 2010, 11:55:11 PM**_](https://bitcointalk.org/index.php?topic=1668.msg21899#msg21899) _Of course, if the network is not being flooded and you're not overly concerned about the current transaction getting held up then it's probably worth preferring to use your 0 conf transactions so that you can "save" the higher priority coins for when the network_ _**is**_ _being flooded._ You should use at least some priority in case a flood comes along before the next block. As long as all dependencies have at least 1 conf, if the transaction doesn't have enough priority at first, the dependencies will age until it does. _**Quote**_ _Gaming the system by including 1000 or so recently turned over BTC to bump the priority as described in my post above still works of course!_ Or managing how much priority you spend on a transaction. The software would have to know your future plans to know whether to spend your priority now or save it for later. I don't think we'll need to get into that much detail though. There's a wide enough difference between normal users and flooders. Priority doesn't have to do everything. Once you know there's a flood, you can add -paytxfee=0.01. Hopefully with priority, your transactions before that should be at worst slow, not stuck. ##### BitcoinTalk #### Re: Need OP_BLOCKNUMBER to allow "time" limited transactions ##### _2010-11-15 18:37:44 UTC_ - [-](https://bitcointalk.org/index.php?topic=1786.msg22119#msg22119) We can't safely do OP_BLOCKNUMBER. In the event of a block chain reorg after a segmentation, transactions need to be able to get into the chain in a later block. The OP_BLOCKNUMBER transaction and all its dependants would become invalid. This wouldn't be fair to later owners of the coins who weren't involved in the time limited transaction. nTimeLock does the reverse. It's an open transaction that can be replaced with new versions until the deadline. It can't be recorded until it locks. The highest version when the deadline hits gets recorded. It could be used, for example, to write an escrow transaction that will automatically permanently lock and go through unless it is revoked before the deadline. The feature isn't enabled or used yet, but the support is there so it could be implemented later. ##### BitcoinTalk #### Re: Transaction / spam flood attack currently under way ##### _2010-11-19 23:50:24 UTC_ - [-](https://bitcointalk.org/index.php?topic=1850.msg22952#msg22952) [_**Quote from: creighto on November 19, 2010, 08:29:12 PM**_](https://bitcointalk.org/index.php?topic=1850.msg22896#msg22896) _Perhaps in addition to the age priority rule recently implimented, there should be a minimum age rule_ _without_ _a transaction fee. Said another way, perhaps a generation rule that says that a free transaction must be 3 blocks deep before it can be transfered again for free. This will still allow real users to immediately spend new funds if they have to, while still permitting real users to reshuffle funds to suit their needs without an overhead cost. I think that this would significantly inhibit the type of spamming attack that is currently underway._ I'm doing something like that. Priority is a more formalised version of the concept you're describing. [_**Quote from: FreeMoney on November 19, 2010, 05:39:44 PM**_](https://bitcointalk.org/index.php?topic=1842.msg22844#msg22844) _As it stands now 3.15 has a lot of free transaction space and that space is given first to transactions with the highest [age]*[value]/[size] correct? Would it be reasonable to make some arbitrary portion of the free space require [age]*[value]/[size] > C ? Maybe set C so that a standard 1BTC transaction can get into the main free area on the next block. And a .1 can get in after waiting about 10 blocks. And make the area which allows [age]*[value]/[size] < C to let in about a dozen transactions or so._ Yes, like this. And the no-priority-requirement area is 3K, about a dozen transactions per block. I just uploaded SVN rev 185 which has a minimal priority requirement for free transactions. Transaction floods are made up of coins that are re-spent over and over, so they depend on their own 0 conf transactions repeatedly. 0 conf transactions have 0 priority, so free transactions like that will have to wait for one transaction to get into a block at a time. Version 0.3.15 doesn't write transactions using 0 conf dependencies unless that's all it has left, so normal users shouldn't usually have a problem with this. I think this is a good compromise short of making the default fee 0.01. It's not so much to ask that free transactions can only be used to turn coins over so often. If you're using free transactions, you're taking charity and there has to be some limit on how often you can use it with the same coins. We've always said free transactions may be processed more slowly. You can help ensure your transactions go through quickly by adding -paytxfee=0.01. ##### BitcoinTalk #### Re: OpenCL miner for the masses ##### _2010-11-20 17:24:20 UTC_ - [-](https://bitcointalk.org/index.php?topic=1334.msg23097#msg23097) [_**Quote from: m0mchil on November 20, 2010, 10:16:19 AM**_](https://bitcointalk.org/index.php?topic=1334.msg23018#msg23018) _updated to SVN 186_ Thanks m0mchil for keeping up on the updates! GPU miners, please upgrade as soon as possible to shut down the free transaction abuse! This version has the new priority-based limit on free transaction spam. [_**Quote from: m0mchil on November 16, 2010, 10:30:41 AM**_](https://bitcointalk.org/index.php?topic=1334.msg22251#msg22251) _Just updated to SVN 181 and fixed getwork patch to wait 60 seconds between rebuilding the block with new transactions. This is actually the behavior of the original client, was forgotten in the patch by mistake. Fixes heavy CPU usage on every getwork request (this became obvious with recent heavy transaction spam). Please upgrade._ Before SVN 184, compiling transactions into a block used an n^2 algorithm. The new efficient single-pass algorithm is orders of magnitude quicker. (O(n) vs O(n^2)/2 algorithm, n=200 maybe 10 to 100 times quicker) ##### BitcoinTalk #### New getwork ##### _2010-11-23 19:50:12 UTC_ - [-](https://bitcointalk.org/index.php?topic=1901.msg23876#msg23876) I uploaded a redesign of m0mchil's getwork to SVN rev 189 (version 31601) m0mchil's external bitcoin miner idea has solved a lot of problems. GPU programming is immature and hard to compile, and I didn't want to add additional dependencies to the build. getwork allows these problems to be solved separately, with different programs for different hardware and OSes. It's also convenient that server farms can run a single Bitcoin node and the rest only run getwork clients. The interface has a few changes: getwork [data] If [data] is not specified, returns formatted hash data to work on: "midstate" : precomputed hash state after hashing the first half of the data "data" : block data "hash1" : formatted hash buffer for second hash "target" : little endian hash target If [data] is specified, tries to solve the block and returns true if it was successful. [data] is the same 128 byte block data that was returned in the "data" field, but with the nonce changed. Notes: - It does not return work when you submit a possible hit, only when called without parameter. - The block field has been separated into data and hash1. - data is 128 bytes, which includes the first half that's already hashed by midstate. - hash1 is always the same, but included for convenience. - Logging of "ThreadRPCServer method=getwork" is disabled, it would be too much junk in the log. ##### BitcoinTalk #### Re: New getwork ##### _2010-11-23 20:55:27 UTC_ - [-](https://bitcointalk.org/index.php?topic=1901.msg23891#msg23891) It's not an exact drop-in replacement. I wanted to clean up the interface a little. It only requires a few changes. ScanHash_ functions aren't going away. BTW, the interface of this is designed to mirror the parameters of that (midstate, data, hash1). ##### BitcoinTalk #### Re: New getwork ##### _2010-11-24 17:21:01 UTC_ - [-](https://bitcointalk.org/index.php?topic=1901.msg24095#msg24095) [_**Quote from: jgarzik on November 24, 2010, 04:47:42 AM**_](https://bitcointalk.org/index.php?topic=1901.msg24008#msg24008) _I suspect something weird going on with ByteReverse (or lack thereof). It's quite unclear whether or not 'data' and 'nonce' must be byte-reversed, and in what way._ getwork does the byte-reversing. midstate, data and hash1 are already big-endian, and you pass data back still big-endian, so you work in big-endian and don't have to do any byte-reversing. They're the same data that is passed to the ScanHash_ functions. You can take midstate, data and hash1, put them in 16-byte aligned buffers and pass them to a ScanHash_ function, like ScanHash(pmidstate, pdata + 64, phash1, nHashesDone). If a nonce is found, patch it into data and call getwork. I should probably change the ScanHash_ functions to use pdata instead of pdata + 64 so they're consistent. target is little endian, it's supposed to be the same as how m0mchil's did it. (if it's not, then it should be fixed) That's the only case where you would use byte reverse. I think you do it like: if ByteReverse((unsigned int*)hash[6]) < (unsigned int*)target[6]. [_**Quote from: DiabloD3 on November 24, 2010, 11:31:11 AM**_](https://bitcointalk.org/index.php?topic=1901.msg24050#msg24050) _Satoshi, please fix your implementation of getwork so it complies with m0mchill's specification_ This is the new spec. It shouldn't be hard to update your miner to use it. The changes are: - It does not return work when you submit a possible hit, only when called without parameter. - The block field has been split into data and hash1. - state renamed to midstate for consistency. - extranonce not needed. ##### BitcoinTalk #### Re: OpenCL miner for the masses ##### _2010-11-24 17:53:09 UTC_ - [-](https://bitcointalk.org/index.php?topic=1334.msg24101#msg24101) A revised version of getwork is now in the official client, but the miners need to be updated a little to use it. ##### BitcoinTalk #### Re: RFC: ship block chain 1-74000 with release tarballs? ##### _2010-11-25 17:51:39 UTC_ - [-](https://bitcointalk.org/index.php?topic=1931.msg24438#msg24438) It's not the downloading that takes the time, it's verifying and indexing it. Bandwidthwise, it's more efficient than if you downloaded an archive. Bitcoin only downloads the data in blk0001.dat, which is currently 55MB, and builds blkindex.dat itself, which is 47MB. Building blkindex.dat is what causes all the disk activity. During the block download, it only flushes the database to disk every 500 blocks. You may see the block count pause at ??499 and ??999. That's when it's flushing. Doing your own verifying and indexing is the only way to be sure your index data is secure. If you copy blk0001.dat and blkindex.dat from an untrusted source, there's no way to know if you can trust all the contents in them. Maybe Berkeley DB has some tweaks we can make to enable or increase cache memory. ##### BitcoinTalk #### Version 0.3.17 ##### _2010-11-25 20:07:36 UTC_ - [-](https://bitcointalk.org/index.php?topic=1946.msg24460#msg24460) Version 0.3.17 is now available. Changes: - new getwork, thanks m0mchil - added transaction fee setting in UI options menu - free transaction limits - sendtoaddress returns transaction id instead of "sent" - getaccountaddress <account> The UI transaction fee setting was easy since it was still there from 0.1.5 and all I had to do was re-enable it. The accounts-based commands: move, sendfrom and getbalance <account> will be in the next release. We still have some more changes to make first. Downloads: [http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.17/](http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.17/) ##### BitcoinTalk #### Re: RFC: ship block chain 1-74000 with release tarballs? ##### _2010-11-26 17:32:01 UTC_ - [-](https://bitcointalk.org/index.php?topic=1931.msg24662#msg24662) I tested it on a slow 7 year old drive, where bandwidth and CPU were clearly not the bottleneck. Initial download took 1 hour 20 minutes. If it's taking a lot longer than that, certainly 24 hours, then it must be downloading from a very slow node, or your connection is much slower than around 15KB per sec (120kbps), or something else is wrong. It would be nice to know what appears to be the bottleneck when that happens. Every 10 minutes or so when the latest block is sent, it should have the chance to change to a faster node. When the latest block is broadcast, it requests the next 500 blocks from other nodes, and continues the download from the one that sends it fastest. At least, that's how it should work. [_**Quote from: jgarzik on November 26, 2010, 02:07:43 AM**_](https://bitcointalk.org/index.php?topic=1931.msg24522#msg24522) [_**Quote from: satoshi on November 25, 2010, 05:51:39 PM**_](https://bitcointalk.org/index.php?topic=1931.msg24438#msg24438) Maybe Berkeley DB has some tweaks we can make to enable or increase cache memory. _Which of the_ [_ACID_](http://en.wikipedia.org/wiki/ACID) _properties do you need, while downloading?_ It may only need more read caching. It has to read randomly all over blk0001.dat and blkindex.dat to index. It can't assume the file is smaller than memory, although it currently still is. Caching would be effective, since most dependencies are recent. Someone should experiment with different Berkeley DB settings and see if there's something that makes the download substantially faster. If something substantial is discovered, then we can work out the particulars. _**Quote**_ _Adding BDB records is simply appending to a log file, until you issue a checkpoint. The checkpoint then updates the main database file._ We checkpoint every 500 blocks. ##### BitcoinTalk #### Re: Version 0.3.17 ##### _2010-11-26 18:23:30 UTC_ - [-](https://bitcointalk.org/index.php?topic=1946.msg24673#msg24673) Laszlo does them, but I haven't asked him to do one for a while because there wasn't anything major. I'll ask him to do this version. ##### BitcoinTalk #### Re: New getwork ##### _2010-11-26 21:31:13 UTC_ - [-](https://bitcointalk.org/index.php?topic=1901.msg24708#msg24708) That's what it does, it returns true/false. ##### BitcoinTalk #### Re: New demonstration CPU miner available ##### _2010-11-26 22:02:41 UTC_ - [-](https://bitcointalk.org/index.php?topic=1925.msg24719#msg24719) You should try it with tcatm's 4-way SSE2 SHA in sha256.cpp. It compiles fine as a C file, just rename sha256.cpp to sha256.c. I was able to get it to work in simple tests on Windows, but not when linked in with Bitcoin. It may have a better chance of working as part of a C program instead of C++. Currently it's only enabled in the Linux build, so if you get it to work you could make it available to Windows users. It's about 100% speedup on AMD CPUs. ##### BitcoinTalk #### Re: Cooperative mining ##### _2010-11-28 16:03:30 UTC_ - [-](https://bitcointalk.org/index.php?topic=1976.msg25119#msg25119) ribuck's description is spot on. Pool operators can modify their getwork to take one additional parameter, the address to send your share to. The easy way for the pool operator would be to wait until the next block is found and divy it up proportionally as: user's near-hits/total near-hits from everyone That would be easier and safer to start up. It also has the advantage that multiple hits from the same user can be combined into one transaction. A lot of your hits will usually be from the same people. The instant gratification way would be to pay a fixed amount for each near-hit immediately, and the operator takes the risk from randomness of having more or less near-hits before a block is found. Either way, the user who submits the hit that solves the block should get an extra amount off the top, like 10 BTC. New users wouldn't really even need the Bitcoin software. They could download a miner, create an account on mtgox or mybitcoin, enter their deposit address into the miner and point it at anyone's pool server. When the miner says it found something, a while later a few coins show up in their account. Miner writers better make sure they never false-positive near-hits. Users will depend on that to check if the pool operator is cheating them. If the miner wrongly says it found something, users will look in their account, not find anything, and get mad at the pool operator. ##### BitcoinTalk #### Re: RFC: ship block chain 1-74000 with release tarballs? ##### _2010-11-28 17:13:01 UTC_ - [-](https://bitcointalk.org/index.php?topic=1931.msg25138#msg25138) Despite everything else said, the current next step is: _**Quote**_ _Someone should experiment with different Berkeley DB settings and see if there's something that makes the download substantially faster. If something substantial is discovered, then we can work out the particulars._ In particular, I suspect that more read caching might help a lot. [_**Quote from: jgarzik on November 28, 2010, 02:33:29 AM**_](https://bitcointalk.org/index.php?topic=1931.msg25017#msg25017) _Another new user on IRC, Linux this time, was downloading at a rate of 1 block every 4 seconds -- estimated total download time around 4 days._ Then something more specific was wrong. That's not due to normal initial download time. Without more details, it can't be diagnosed. If it was due to slow download, did it speed up after 10-20 minutes when the next block broadcast should have made it switch to a faster source? debug.log might have clues. How fast is their Internet connection? Was it steadily slow, or just slow down at one point? _**Quote**_ _We have the hashes for genesis block through block 74000 hardcoded (compiled) into bitcoin, so there's no reason why we shouldn't be able to automatically download a compressed zipfile of the block database from_ _anywhere__, unpack it, verify it, and start running._ The 74000 checkpoint is not enough to protect you, and does nothing if the download is already past 74000. -checkblocks does more, but is still easily defeated. You still must trust the supplier of the zipfile. If there was a "verify it" step, that would take as long as the current normal initial download, in which it is the indexing, not the data download, that is the bottleneck. [_**Quote from: jgarzik on November 28, 2010, 07:33:55 AM**_](https://bitcointalk.org/index.php?topic=1931.msg25058#msg25058) _Presumably at some point there will be a lightweight client that only downloads block headers, but there will still be hundreds of thousands of those..._ 80 bytes per header and no indexing work. Might take 1 minute. _**Quote**_ _uncompressed data using a protocol (bitcoin P2P) that wasn't designed for bulk data transfer._ The data is mostly hashes and keys and signatures that are uncompressible. The speed of initial download is not a reflection of the bulk data transfer rate of the protocol. The gating factor is the indexing while it downloads. ##### BitcoinTalk #### Re: Is safe running bitcoins with the same wallet on more computers simultaneously? ##### _2010-11-28 18:06:39 UTC_ - [-](https://bitcointalk.org/index.php?topic=1986.msg25154#msg25154) _**Quote**_ _Will it be synchronized automatically?_ Very much not. Using multiple copies of wallet.dat is not recommended or supported, in fact all of Bitcoin is designed to defeat that. Both copies will get screwed up. If you're trying to consolidate your generated coins into one wallet, a better solution now is to run getwork miners on the additional systems. jgarzik has a CPU miner, and it supports tcatm's 4-way SSE2, so on Windows it's up to twice as fast as the built-in SHA if you have an AMD or recent Intel (core 3, 5 or 7). New demonstration CPU miner available: [http://BitcoinTalk.org/index.php?topic=1925.0](http://bitcointalk.org/index.php?topic=1925.0) ##### BitcoinTalk #### Re: RFC: ship block chain 1-74000 with release tarballs? ##### _2010-11-29 20:19:12 UTC_ - [-](https://bitcointalk.org/index.php?topic=1931.msg25449#msg25449) It seems like you're inclined to assume everything is wrong more than is actually so. Writing the block index is light work. Building the tx index is much more random access per block. I suspect reading all the prev txins is what's slow. Read caching would help that. It's best if the DB does that. Maybe it has a setting for how much cache memory to use. _**Quote**_ _1) bitcoin should be opening databases, not just environment, at program startup, and closing database at program shutdown._ Already does that. See CDB. The lifetime of the (for instance) CTxDB object is only to support database transactions and to know if anything is still using the database at shutdown. _**Quote**_ _And, additionally, bitcoin forces a database checkpoint, pushing all transactions from log into main database._ If it was doing that it would be much slower. It's supposed to be only once a minute or 500 blocks: if (strFile == "blkindex.dat" && IsInitialBlockDownload() && nBestHeight % 500 != 0) nMinutes = 1; dbenv.txn_checkpoint(0, nMinutes, 0); Probably should add this: if (!fReadOnly) dbenv.txn_checkpoint(0, nMinutes, 0); _**Quote**_ _2) For the initial block download, txn commit should occur once every N records, not every record. I suggest N=1000._ Does transaction commit imply flush? That seems surprising to me. I assume a database op wrapped in a transaction would be logged like any other database op. Many database applications need to wrap almost every pair of ops in a transaction, such as moving money from one account to another. (debit a, credit b) I can't imagine they're required to batch all their stuff up themselves. In the following cases, would case 1 flush once and case 2 flush twice? case 1: write write write write checkpoint case 2: begin transaction write write commit transaction begin transaction write write commit transaction checkpoint Contorting our database usage will not be the right approach. It's going to be BDB settings and caching. ##### BitcoinTalk #### Re: Incompatible wallet format with latest bitcoin-git ? ##### _2010-11-30 19:02:31 UTC_ - [-](https://bitcointalk.org/index.php?topic=2007.msg25799#msg25799) What was this wallet used with? An early accounts patch or git build? It's while loading the wallet. I assume it must be in this: else if (strType == "acentry") { string strAccount; ssKey >> strAccount; uint64 nNumber; ssKey >> nNumber; if (nNumber > nAccountingEntryNumber) nAccountingEntryNumber = nNumber; } You could check that with this: else if (strType == "acentry") { string strAccount; assert(!ssKey.empty()); ssKey >> strAccount; uint64 nNumber; if (ssKey.size() != 8 ) printf("***** %s %d ", strAccount.c_str(), ssKey.size()); assert(ssKey.empty() == false); ssKey >> nNumber; if (nNumber > nAccountingEntryNumber) nAccountingEntryNumber = nNumber; } Was there an interim version of accounts on git at some point that had just ("acentry", "account") for the key? If you have gdb, you could run it in gdb and do a backtrace. gdb --args bitcoin ... run (wait for exception) bt **Martii Malmi (AKA Sirius) “COPA trial” email #238** **Date: Wed, 01 Dec 2010 00:58:37 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: [Fwd: Bitcoin.org is down]** **To: Martti Malmi <mmalmi@cc.hut.fi>** -------- Original Message -------- Subject: Bitcoin.org is down Date: Tue, 30 Nov 2010 18:27:02 -0600 From: theymos <theymos@mm.st> To: satoshin@gmx.com Bitcoin.org has been down for several hours. ##### BitcoinTalk #### Re: RFC: ship block chain 1-74000 with release tarballs? ##### _2010-12-01 21:25:39 UTC_ - [-](https://bitcointalk.org/index.php?topic=1931.msg26016#msg26016) That's a good optimisation. I'll add that next time I update SVN. More generally, we could also consider this: dbenv.set_lk_max_objects(10000); dbenv.set_errfile(fopen(strErrorFile.c_str(), "a")); /// debug dbenv.set_flags(DB_AUTO_COMMIT, 1); + dbenv.set_flags(DB_TXN_NOSYNC, 1); ret = dbenv.open(strDataDir.c_str(), DB_CREATE | DB_INIT_LOCK | DB_INIT_LOG | We would then rely on dbenv.txn_checkpoint(0, 0, 0) in CDB::Close() to flush after wallet writes. **Martii Malmi (AKA Sirius) “COPA trial” email #239** **Date: Thu, 02 Dec 2010 22:00:56 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: What was the bitcoin.org outage?** **To: Martti Malmi <mmalmi@cc.hut.fi>** Do you know what caused that outage? Did it need to be rebooted, or was it a DoS or something? The IP was pingable during the outage. Did you get back to davidonpda about his doing a mirror backup? I think that's a really good idea. Do you do any backups, or the VPS do any for you automatically? ----

msg15150msg15167msg15176msg15360msg15248msg15366237msg15660msg15672msg15682msg15741msg13828msg16316msg17924msg17965msg15697msg18241msg17955msg18074msg18245msg18246msg18105msg18250msg18349msg18508msg18511msg21766msg21896msg21897msg21959msg21899msg22119msg22952msg22896msg22844msg23097msg23018msg22251msg23876msg23891msg24095msg24008msg24050msg24101msg24438msg24460msg24662msg24522msg24673msg24708msg24719msg25119msg25138msg25017msg25058msg25154msg25449msg25799238msg26016239