Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Rqonc-0008CM-Hr for bitcoin-development@lists.sourceforge.net; Fri, 27 Jan 2012 16:37:16 +0000 X-ACL-Warn: Received: from nm11.bullet.mail.ne1.yahoo.com ([98.138.90.74]) by sog-mx-1.v43.ch3.sourceforge.com with smtp (Exim 4.76) id 1RqonX-0001C6-4g for bitcoin-development@lists.sourceforge.net; Fri, 27 Jan 2012 16:37:16 +0000 Received: from [98.138.90.54] by nm11.bullet.mail.ne1.yahoo.com with NNFMP; 27 Jan 2012 16:37:05 -0000 Received: from [98.138.89.163] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 27 Jan 2012 16:37:05 -0000 Received: from [127.0.0.1] by omp1019.mail.ne1.yahoo.com with NNFMP; 27 Jan 2012 16:37:05 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 556879.44871.bm@omp1019.mail.ne1.yahoo.com Received: (qmail 14192 invoked by uid 60001); 27 Jan 2012 16:37:05 -0000 X-YMail-OSG: _HZVm3oVM1kdL4bQWlRgrVK0d1brbTrtIZQF17ZAAn1qY2q .JV_sDRzHYId2TKCBRlFSmXhiRKUIoyh5Mk2ct1lqSnSGxp6_je3K56oqnwy 9o0npTmoR6Y9LLv32FYDKFIUP4J2FtvjIG3SXES6e6sgHaMa8MiG0Tm.jce6 9mqX4yl0NUqI8RZB3Gu54BP9lG8saCp9mKGycZKwifUQ7is.3ugD7kwARCkx fihbiMjYfc9f6XiCXwene7pduNwoK3OfphIb6OvxHu0sqGunHeqqSaWORejj KNklCQ7h03wNWFaQFDqOyNR9z3gpoDrprBacQHQ2reIGJd4wYPPSeK9wkhI6 EYe5XrjWxqazyHmwNpaB.NEhSkQM3stSqHbk6aDkjEuWKB.Is2MuqLQ63X6l ukErkgVxkk6I85CSDCPZz Received: from [92.20.138.208] by web121001.mail.ne1.yahoo.com via HTTP; Fri, 27 Jan 2012 08:37:05 PST X-Mailer: YahooMailWebService/0.8.116.331537 References: <1327681998.52230.YahooMailNeo@web121001.mail.ne1.yahoo.com> Message-ID: <1327682225.4658.YahooMailNeo@web121001.mail.ne1.yahoo.com> Date: Fri, 27 Jan 2012 08:37:05 -0800 (PST) From: Amir Taaki To: "bitcoin-development@lists.sourceforge.net" In-Reply-To: <1327681998.52230.YahooMailNeo@web121001.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="344044665-1364534497-1327682225=:4658" X-Spam-Score: 0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [98.138.90.74 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (zgenjix[at]yahoo.com) -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -0.4 AWL AWL: From: address is in the auto white-list X-Headers-End: 1RqonX-0001C6-4g Subject: Re: [Bitcoin-development] GetBlocksToMaturity X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Amir Taaki List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 16:37:16 -0000 --344044665-1364534497-1327682225=:4658 Content-Type: text/plain; charset=us-ascii Actually now I'm thinking- I reckon it is so that your transaction gets accepted by the network when it is sent out. At around 20 confirmations, you can be sure that the rest of the network also has 100 confirmations off the original mined block. Otherwise at 100 confirms, you may have a chain ahead of everyone else or there might be a temporary network partition (islanding) that causes another fork to get built up, then when they rejoin, not everyone has 100 confirms... ________________________________ From: Amir Taaki To: "bitcoin-development@lists.sourceforge.net" Sent: Friday, January 27, 2012 4:33 PM Subject: GetBlocksToMaturity Why add 20 to COINBASE_MATURITY there? The underlying protocol accepts spent transactions at 100 (COINBASE_MATURITY) so this seems more like a measure to put people off spending until 120 confirms. If you are determined enough to hack your client, you can still spend before 120 but after 100. Why is this? Did Satoshi overestimate how many competing races there would be between mined blocks? --344044665-1364534497-1327682225=:4658 Content-Type: text/html; charset=us-ascii
Actually now I'm thinking- I reckon it is so that your transaction gets accepted by the network when it is sent out. At around 20 confirmations, you can be sure that the rest of the network also has 100 confirmations off the original mined block.

Otherwise at 100 confirms, you may have a chain ahead of everyone else or there might be a temporary network partition (islanding) that causes another fork to get built up, then when they rejoin, not everyone has 100 confirms...

From: Amir Taaki <zgenjix@yahoo.com>
To: "bitcoin-development@lists.sourceforge.net" <bitcoin-development@lists.sourceforge.net>
Sent: Friday, January 27, 2012 4:33 PM
Subject: GetBlocksToMaturity

Why add 20 to COINBASE_MATURITY there?

The underlying protocol accepts spent transactions at 100 (COINBASE_MATURITY) so this seems more like a measure to put people off spending until 120 confirms. If you are determined enough to hack your client, you can still spend before 120 but after 100.

Why is this?

Did Satoshi overestimate how many competing races there would be between mined blocks?


--344044665-1364534497-1327682225=:4658--