From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 04 Sep 2025 17:43:20 -0700 Received: from mail-oa1-f58.google.com ([209.85.160.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uuKXv-0007p7-M6 for bitcoindev@gnusha.org; Thu, 04 Sep 2025 17:43:20 -0700 Received: by mail-oa1-f58.google.com with SMTP id 586e51a60fabf-319c4251787sf1998968fac.2 for ; Thu, 04 Sep 2025 17:43:19 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1757032993; cv=pass; d=google.com; s=arc-20240605; b=eW9ARFW4udDrIVk6QY14F1NedF79POsV641tBFH+QDEXjxQVteD4OEoQmvnn+x1CsN JU5gkI9UjC7BmbS0zVFlIrdrnEGAuCsquaI7Muz/TTKnXOQCKELaD7ak7jwHmgcJJn/J M1yd++BH70PTKkU88ADj/t5TDyYH/DcXdCfqyLCz0vwXTWCZiX2Fdxz72n3uavpYuCQT kf/8in4QKoGoG2TGP35uPorq7HTqKx1uh1LIhFmyGxPyUOvmSOM63oKHfVZezA3X+qjr h3mPU0PJVgQS5ws4bBZyBPd36kIPk6wh/ghuZnoU7DH5/VdWjcfgvzmMsSHzkylmNBhX CHlw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=OFHmAo1ae16rWKyj/ahzYeXfnz/ndkPUYyzdL0Uf9Pw=; fh=CMNLFIECs+hXmPLLk6ZLqdCiPXvWo+qiS1pyw/VUB9U=; b=aDoBqCQDR3St3kPPhRpX4K/gJlGvPN0sUd5EUCipIVe1sOFodRvJYQLEqq9zoIKyfd pLGlhs2Az/Y4pOxDugao03HJxHVx2QMYInM/6JqFuV8YfXYbCUWTHrpzDg7W7WbLFdI0 sZYI98u3IfIv/QOP/tOOz3tyqlP3iS00zpO58lyVty5oSdO9ugV5RJCIv1XXHTyUHC7H 11mD9P4dYoeHK2TRFrOiNX661m3H41Ajk6ZubHX7aT1ml+Y/9r63ych6UapD3ebqxnw7 Jb/Z0KV5EPWnNdAG/7fmvoUK4glIS4vUNCz76yaEatC7Ee5tOz3O2miJsn3K4DrWVAmO m0Mw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=jLUdrm+L; spf=pass (google.com: domain of laolu32@gmail.com designates 2607:f8b0:4864:20::b31 as permitted sender) smtp.mailfrom=laolu32@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1757032993; x=1757637793; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=OFHmAo1ae16rWKyj/ahzYeXfnz/ndkPUYyzdL0Uf9Pw=; b=PNxNKCKs5itj44mHin2fxXQrZ/rF2IgjHYEK48rzqOXPv8haiITtuNDUv8Z90eUpsj i5sbFTc0EWCsmEMuLyU7D7roWE9cntDqGlG70A+TugUb6uCq2lAO3W3YR5vH8pB6i4L0 CheslYRnNRklQntvKA28PSLcbH5C5HStRQZbmh9odFyNtqTwTjExUQWWswmxVxS0HB+8 w5WdmYTLN/sjk33R/Luc+AWcIUxA+BNrt0yl5q2PXUzbqBQgFofvHcy9t5WHcqbKzwCd UoKZkoJAbR3+/gSD1q7JiuQQgXe4BYTilzs3XFDahTiQCcDOCd4v2zAUQz2FjUMYfJsr ahHA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1757032993; x=1757637793; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=OFHmAo1ae16rWKyj/ahzYeXfnz/ndkPUYyzdL0Uf9Pw=; b=Td3eiiXaEBqpSCeZazlHPytKltCN0FP+mgjH8YumJSjW1u1jJ6Mq5axs0CQRKhmAe7 Ar7xw0rW2TiLHdxkApHQzUMPteEmeQIOH6+nFKVUifOt0a/lgZ+xCInHXPEhdbkoyi08 +pVL/RFFuci+yXrvu2t/gDfILi4ITx+3sqlc+mxwLIxRehecKf29xPz7EYz08JJh+23X kxej3VktNbl8qRfkap3PMH1Y7IzM9m3C/ns+Hkjrjs1MX6Ug+t7mSPvOhmAtYasIvxTX DacO4SNi+YKXKaxk89bKx6wc2/K9tPxhv7dJwsLj8e+vWfixGH4WJelc0QqSfCmqwpNk 4zQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757032993; x=1757637793; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-beenthere:x-gm-message-state:sender:from :to:cc:subject:date:message-id:reply-to; bh=OFHmAo1ae16rWKyj/ahzYeXfnz/ndkPUYyzdL0Uf9Pw=; b=P6v8ZPTYOa1GeEUuj64nfVHC1DhZHaAT4bJoR8ONmfsm/F5czJ83knKUapcTSg3jzx s6EbK6EUS2J8OLO17aMkOs82ucR+38Zl77mPLUlUa3Fg6RgyIhSiuBqJhhZ5SPAH+xui OKCM2WP0RpVpTY8oo5EAhU3+pp7oVxAzqOSWqGVHeyuJ4BfWMSZ0w9SMMCdapa8CJki0 eNBryLzOG9cLu0Ry+e40HRulA91F3v2dvup4jDDopD+oihP1HKEHlKntp5u1ZDtBzYnG Dc+pDFDfVoUmngop+LUNrP6k4+jS8iExSMHVyTIjH0w21ia7ui9TLV3JaurXBTQooLJd Af7w== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUibxziTabHdBqCGKjAezVxF7ZXcyYZCmj1/dRM6uXXPmLGuXl6Alf7nd4Z1iICdQnjtAzM3bz+u6jH@gnusha.org X-Gm-Message-State: AOJu0YzcqyjfST/9sX+phvrtZUDvoYpMFiAHnoH4YbUa5nuGF1/yS2fE tAluH7UaS567KlIGu23YibPWEBeNNnV/P7EuRwjimjfb0YBhnNgoEEwU X-Google-Smtp-Source: AGHT+IGaUdF0J3znnNPGJjT5dVhS0fIdKETcRUIffpckTIpBk/uwOJNouEvMsDNzwShmL9x4DFMYuA== X-Received: by 2002:a05:6870:c693:b0:315:9347:9260 with SMTP id 586e51a60fabf-3196334011bmr10749930fac.32.1757032992751; Thu, 04 Sep 2025 17:43:12 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZdx3vGCaq/AyyTZFL9nuNouavNGGOwshl7hT4VuKSmiSQ== Received: by 2002:a05:6871:81d1:10b0:31a:4dac:cdc3 with SMTP id 586e51a60fabf-32126fe48ebls71464fac.1.-pod-prod-01-us; Thu, 04 Sep 2025 17:43:09 -0700 (PDT) X-Received: by 2002:a05:6808:6a89:b0:438:40ff:a8e7 with SMTP id 5614622812f47-43840ffac0fmr2293170b6e.37.1757032989186; Thu, 04 Sep 2025 17:43:09 -0700 (PDT) Received: by 2002:a05:620a:4729:b0:80d:5a8b:a44e with SMTP id af79cd13be357-8111e280b05ms85a; Thu, 4 Sep 2025 15:46:39 -0700 (PDT) X-Received: by 2002:a05:622a:1a82:b0:4ae:f855:77b0 with SMTP id d75a77b69052e-4b31d546bb6mr247441631cf.0.1757025998297; Thu, 04 Sep 2025 15:46:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1757025998; cv=none; d=google.com; s=arc-20240605; b=YezGk+3KhvjPPdGnhwnPqGFixVpESRV1Oo7fwikS2d7d0dBWUjJ0TPK4k/FMOIWV13 fp/zvm2gH8MqYjEkC8K1aNcsb9TXK64sAiaBNivmBr3uynGyQqxaH9Al8StbCmlPRsN0 PAJmPQGu73kHGurtAoNL9M723MXwuKL5hpDkkGuKkajDRLaqqyoO3XfVHsyQUKx92u6j SNOKMoO2kgmN5U+1cVS3eg+2p/E1JNgRAE3TCyGJVZhkFKhXkE4dAtWEnY50klHaJgNX Zn3fTxG/usGZb9tjKA2FcBU2aROARm8Rghw4XnhRrxYmdL7FCP2pjBOI3CN7EC91I24U PEVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=dhRev0eP3w9k8HsWOq7RBdNyWe8db5U1Q89VVGfF+Pg=; fh=+Duu3Cp77aXfHDD1ma61XeBuViahPkcQ600hmLognUE=; b=PWkdF3lHGwXbor3hAX0p4HxJ+f/Vf1pUAIHYw0ezAk3zWPVGctSjNUGAlx5ajLg2e/ BiZjoS6QUeqLKRnTIJa2WJkfGj5K4M+y3dICxYkowdVNEHEDORK5Ae7jjgMLSsH1Lf/V tOF57o34zakzrz+FM5cZkBQeeSUR5/38fSd8Zfnd8mJSJi+DOTJTK/oL3cYH30tr1U+N GM4GfU1UoO0yjvCxKzCAongLvbhkNvH4/H8JeEOvb2wJ7FNtkMthp3ulQQY9XS35zZG1 xfdgcPWJwiiXf6JAdRMIFnwpJ1F5nh75atnIh8NQDLk+3wx1MinXQCBl0KADzjt56WrW e4cw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=jLUdrm+L; spf=pass (google.com: domain of laolu32@gmail.com designates 2607:f8b0:4864:20::b31 as permitted sender) smtp.mailfrom=laolu32@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com. [2607:f8b0:4864:20::b31]) by gmr-mx.google.com with ESMTPS id af79cd13be357-80aaa832cdbsi26648085a.7.2025.09.04.15.46.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Sep 2025 15:46:38 -0700 (PDT) Received-SPF: pass (google.com: domain of laolu32@gmail.com designates 2607:f8b0:4864:20::b31 as permitted sender) client-ip=2607:f8b0:4864:20::b31; Received: by mail-yb1-xb31.google.com with SMTP id 3f1490d57ef6-e9d71a04d78so1291164276.1 for ; Thu, 04 Sep 2025 15:46:38 -0700 (PDT) X-Gm-Gg: ASbGncuib0z+6jukNiyQOJCRqBQON65+CPYZbgdQhfvASp8KHRi5MILmZBzYgyL/opo 7JiUWv4vCJrVlPAdSz6FBkEoiq5na+cb9KVqijvIBbIbr9BoxWu0EL9pDwOQaWjlQHtVuB4954x SFcjAwMAIl3JEd2HUeccqRBkacsIzLFatvMKYO3o+B93jOqQ9OoXMv8pMKyIdSLKi0OTMoVirPi F//a1QEK4k4W/i5uls= X-Received: by 2002:a53:d005:0:b0:5fc:2f89:8892 with SMTP id 956f58d0204a3-601780cc565mr4332651d50.27.1757025997493; Thu, 04 Sep 2025 15:46:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Olaoluwa Osuntokun Date: Thu, 4 Sep 2025 15:46:26 -0700 X-Gm-Features: Ac12FXwQQWuW-XNDbXk7ZFVeK1fniWOH-bSEvGYfROHmC3O-K1YcNvZaRv8vbM4 Message-ID: Subject: Re: [bitcoindev] [BIP Proposal] OP_TWEAKADD To: jeremy Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000711ab3063e017e61" X-Original-Sender: laolu32@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=jLUdrm+L; spf=pass (google.com: domain of laolu32@gmail.com designates 2607:f8b0:4864:20::b31 as permitted sender) smtp.mailfrom=laolu32@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) --000000000000711ab3063e017e61 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Second, why fail if the passed scalar is greater than the curve order vs > just reducing modulo the order and using that value? Thinking about it a bit more, I think this is totally the right decision an= d makes a lot of sense. The probability that a random sha256 output will be greater than the order of the curve is ~1/2^128, and is something that any key generation code or other related application needs to deal with. Eliminating all sources of malleability in newly proposed op codes is important as it serves to increase the binding of transactions w.r.t blocks. Stronger binding of transactions to blocks post segwit (otherwise possible to malleate transactions, causing the witness commitment validation to fail for an otherwise valid block), helps to mitigate a class of active relay impediment attacks and minimizes front-running/extractable value. -- Laolu On Wed, Sep 3, 2025 at 7:38=E2=80=AFPM Olaoluwa Osuntokun wrote: > > Hi Jeremy, > > Cool idea, I had a similar one myself a while back. Shows that great chef= s > think alike ;). Here're some questions that came to mind as I was reviewi= ng > the doc. > > First, why accept only x-only keys? > > From the PoV of Bitcoin Script today, they aren't used anywhere within th= e > execution environment. They also add some complexity to protocols that ne= ed > to accept them as input for further manipulation. They are indeed used fo= r > Taproot output public keys, but those keys don't ever make their way down > into Script as an op code argument. > > The musig2 BIP originally accepted x-only keys as input, but was switched > to > instead accept normal compressed public keys in version v0.8.0 [1]. The > switch over enabled some simplifications in the BIP, as it enabled > eliminating one of the accumulator variables. For more details, see the > discussion that led to this change [2]. > > This comment from Tim resonates with my experience wrangling with bugs > introduced by improper/implicit handling of x-only keys over the years: > > > Sigh yeah, x-only keys save a byte on chain but it seems the price we p= ay > > is a high engineering complexity. I think it's fair to say that noone h= ad > > really anticipated this [1]. > > Second, why fail if the passed scalar is greater than the curve order vs > just reducing modulo the order and using that value? > > This would mean that in some cases, the direct value of a hash can't be > used > as the scalar tweak. The probability of this happening for sha256 outputs > is > very low, but it presents developers with yet another thing to keep in mi= nd > in order to use the op code safely. > > You bring up the point that this allows the side stepping of a new source > of > witness malleability, but in the year of Satoshi 16 (2025), aside from > relay > nuisance shenanigans, is this something developers still need to care > about? > > Third, why allocate a cost of 50 op cost vs something lower to better > account for the difference in operation vs normal `OP_CHECKSIG`? > > Validating a BIP-340 signature requires an extra scalar base mult > (ignoring the Strauss-Shamir trick for double scalar mult for a sec) vs > `OP_TWEAKADD` as it's defined in your draft BIP. As a result, one could > argue that the op code should have a lower cost vs `OP_CHECKSIG`. > > -- Laolu > > [1]: https://github.com/jonasnick/bips/pull/37 > [2]: https://github.com/jonasnick/bips/issues/32 > > On Sat, Aug 23, 2025 at 10:36=E2=80=AFAM jeremy wrote: > >> Hi all, >> >> I've made a draft BIP writeup of an (often discussed) simple opcode, >> OP_TWEAKADD, deployable as an OP_SUCCESSx upgrade. >> >> https://github.com/bitcoin/bips/pull/1944 >> >> This opcode is relatively simple. The main design choices are: >> >> 1) Verify v.s. Push semantics -- Push, for succinctness on-chain >> 2) Argument order -- Key on top, for tweak in witness >> 3) Plain tweak or something else -- Plain tweak, if hashing is desirable >> the user can do it. The most flexible is to do a plain tweak. Future wor= k >> could add TapTree opcodes to construct taproot tweaks. >> >> Feedback and discussion are welcome. >> >> Best, >> >> Jeremy >> >> [^1] OP_SHA256 in these example prevents key-cancellation. >> >> -- >> You received this message because you are subscribed to the Google Group= s >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/bc9ff794-b11e-47bc-8840-55b= 2bae22cf0n%40googlegroups.com >> >> . >> > --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= CAO3Pvs_nvhaDLtxfS2B1TL06o5W9q0Zv1k26xR%2BPRGS4ZEJsTQ%40mail.gmail.com. --000000000000711ab3063e017e61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Second, why fail if the passed scalar is greater= than the curve order vs
> just reducing modulo the order and using t= hat value?

Thinking about it a bit more, I think this is totally the= right decision and
makes a lot of sense.

The probability that a= random sha256 output will be greater than the order
of the curve is ~1/= 2^128, and is something that any key generation code or
other related ap= plication needs to deal with.

Eliminating all sources of malleabili= ty in newly proposed op codes is
important as it serves to increase the = binding of transactions w.r.t blocks.

Stronger binding of transacti= ons to blocks post segwit (otherwise possible
to malleate transactions, = causing the witness commitment validation to fail
for an otherwise valid= block), helps to mitigate a class of active
relay impediment attacks an= d minimizes front-running/extractable value.

-- Laolu

On Wed, Sep 3, 2025 at 7:38=E2=80=AFPM Olaoluwa Osuntokun = <laolu32@gmail.com> wrote:
=

Hi Jeremy,

Cool idea, I had a similar one myself = a while back. Shows that great chefs
think alike ;). Here're some qu= estions that came to mind as I was reviewing
the doc.

First, why = accept only x-only keys?

From the PoV of Bitcoin Script today, they= aren't used anywhere within the
execution environment. They also ad= d some complexity to protocols that need
to accept them as input for fur= ther manipulation. They are indeed used for
Taproot output public keys, = but those keys don't ever make their way down
into Script as an op c= ode argument.

The musig2 BIP originally accepted x-only keys as inpu= t, but was switched to
instead accept normal compressed public keys in v= ersion v0.8.0 [1]. The
switch over enabled some simplifications in the B= IP, as it enabled
eliminating one of the accumulator variables. For more= details, see the
discussion that led to this change [2].

This co= mment from Tim resonates with my experience wrangling with bugs
introduc= ed by improper/implicit handling of x-only keys over the years:

>= ; Sigh yeah, x-only keys save a byte on chain but it seems the price we pay=
> is a high engineering complexity. I think it's fair to say tha= t noone had
> really anticipated this [1].

Second, why fail if= the passed scalar is greater than the curve order vs
just reducing modu= lo the order and using that value?

This would mean that in some cas= es, the direct value of a hash can't be used
as the scalar tweak. Th= e probability of this happening for sha256 outputs is
very low, but it p= resents developers with yet another thing to keep in mind
in order to us= e the op code safely.

You bring up the point that this allows the si= de stepping of a new source of
witness malleability, but in the year of = Satoshi 16 (2025), aside from relay
nuisance shenanigans, is this someth= ing developers still need to care about?

Third, why allocate a cost = of 50 op cost vs something lower to better
account for the difference in= operation vs normal `OP_CHECKSIG`?

Validating a BIP-340 signature = requires an extra scalar base mult
(ignoring the Strauss-Shamir trick fo= r double scalar mult for a sec) vs
`OP_TWEAKADD` as it's defined in = your draft BIP. As a result, one could
argue that the op code should hav= e a lower cost vs `OP_CHECKSIG`.

-- Laolu

[1]: https://github.co= m/jonasnick/bips/pull/37
[2]: https://github.com/jonasnick/bips/issu= es/32

On Sat, Aug 23, 2025 at 10:36=E2=80=AFAM jer= emy <jerem= y.l.rubin@gmail.com> wrote:
Hi all,

I've made a dr= aft BIP writeup of an (often discussed) simple opcode, OP_TWEAKADD, deploya= ble as an OP_SUCCESSx upgrade.

https://github.com/bitcoin/= bips/pull/1944

This opcode is relatively simple. The= main design choices are:

1) Verify v.s. Push sema= ntics -- Push, for succinctness on-chain
2) Argument order -- Key= on top, for tweak in witness
3) Plain tweak or something else --= Plain tweak, if hashing is desirable the user can do it. The most flexible= is to do a plain tweak. Future work could add TapTree opcodes to construct= taproot tweaks.

Feedback and discussion are = welcome.

Best,

Jeremy=

[^1] OP_SHA256 in these example prevents key= -cancellation.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.googl= e.com/d/msgid/bitcoindev/bc9ff794-b11e-47bc-8840-55b2bae22cf0n%40googlegrou= ps.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/= msgid/bitcoindev/CAO3Pvs_nvhaDLtxfS2B1TL06o5W9q0Zv1k26xR%2BPRGS4ZEJsTQ%40ma= il.gmail.com.
--000000000000711ab3063e017e61--