From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Qp4e7-00053I-Of for bitcoin-development@lists.sourceforge.net; Thu, 04 Aug 2011 20:35:59 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.47 as permitted sender) client-ip=209.85.216.47; envelope-from=gmaxwell@gmail.com; helo=mail-qw0-f47.google.com; Received: from mail-qw0-f47.google.com ([209.85.216.47]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Qp4e7-0007S1-0S for bitcoin-development@lists.sourceforge.net; Thu, 04 Aug 2011 20:35:59 +0000 Received: by qwh5 with SMTP id 5so1710551qwh.34 for ; Thu, 04 Aug 2011 13:35:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.2.155 with SMTP id 27mr1018186qcj.216.1312490153536; Thu, 04 Aug 2011 13:35:53 -0700 (PDT) Received: by 10.229.3.141 with HTTP; Thu, 4 Aug 2011 13:35:53 -0700 (PDT) In-Reply-To: <43351.137.56.163.46.1312351847.squirrel@lavabit.com> References: <43351.137.56.163.46.1312351847.squirrel@lavabit.com> Date: Thu, 4 Aug 2011 16:35:53 -0400 Message-ID: From: Gregory Maxwell To: bgroff@lavabit.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -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.0 T_TO_NO_BRKTS_FREEMAIL To: misformatted and free email service -0.0 AWL AWL: From: address is in the auto white-list X-Headers-End: 1Qp4e7-0007S1-0S Cc: Bitcoin Development Subject: Re: [Bitcoin-development] Discussion related to pull 349 and pull 319 (escrow transactions) X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 20:35:59 -0000 On Wed, Aug 3, 2011 at 2:10 AM, wrote: > Thank you! =C2=A0(I think you mean 319 here) Correct. > With Eligius mining !IsStandard transactions and probably other pools ope= n > to the idea, I am hopeful that we can quickly get 30%+ of mining power to > upgrade, which means that we could still mine these in a reasonable time > frame (under 1 hour). It's not just a matter of mining power, it's also a question of propagation. Matt and I tried to perform a non-standard transaction weeks ago and weren't able to get in mined after many hours. (we eventually double spent the input with a normal transaction in order to make it go away, interestingly one point about non-propagating txn is that they're extra vulnerable to double spending by a standard txn, as the non-standard one won't preclude the propagation of the standard one) >From discussion on IRC it seemed clear enough that the current focus on maturity/bugfixes is probably going to delay your full patch, but the IsStandard part is uncontroversial and could go in quickly. Based on that I think it would be very useful to split 319 into two pull requests: one which does the IsStandard change, and one which adds the full escrow feature set. This way when the escrow patch does enter the mainline client it will be meet up with a network which is happy to handle its transactions. (and people who are eager to use escrow can use modified clients on the main network before that point in time) > I'm not sure I see the problem here. CScript.operator<< currently insert= s > values into scripts using the shortest possible sequence. Ah for some reason I thought your current code did not always produce the shortest sequence. If so, I see no reason to block on the other pull.