Delivery-date: Thu, 13 Mar 2025 20:33:31 -0700
Received: from mail-yb1-f189.google.com ([209.85.219.189])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCY3VBMZVAMRBAGHZ27AMGQEZ6XIQDA@googlegroups.com>)
	id 1tsvnd-0003ge-Vt
	for bitcoindev@gnusha.org; Thu, 13 Mar 2025 20:33:31 -0700
Received: by mail-yb1-f189.google.com with SMTP id 3f1490d57ef6-e582bfcada6sf2917868276.1
        for <bitcoindev@gnusha.org>; Thu, 13 Mar 2025 20:33:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1741923204; x=1742528004; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=DYgZCPsa0glvWARJH+pfbMMs+AJ3+XfL5H5kBmyXwJM=;
        b=iT8YVLu+ExuAkL9K+Fc3zVanSoWsRjgTKvfDMgoFkE/UAmh6iM2RsjDLaPsDCEuDEy
         MKo4CIU8k/prM0K9c0tL29bZK7dlLYl2zpN4croAd+NjxsgALLBDJYtbGpi2Bpqzm/65
         ahFuaZjUFmhn+hhyMvC98B7ke2DtxDvRksDqIHvbyjQI2g0+QJ4Je8F8oA/5TSsrrSqb
         yGSIlVzHnxjhTZASBGf96K43vIdbCFuiyC3kWmXYBMy2N02gcd5pLLXct7OKqEfJ0Kqz
         /W/OVazNJabBIBA1L79hBW9CH+UdgMq8vttHnh4andrNZ2AhIzmmT39rsQZWUdD+mwl3
         00Xg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1741923204; x=1742528004; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=DYgZCPsa0glvWARJH+pfbMMs+AJ3+XfL5H5kBmyXwJM=;
        b=hMtdYXLGH0FR781i7KbwQi4F5Ppr8CgQKF7ifcgacXsra+l5j/Y3JjNaY9tuGEBvCj
         dDS6TX0Ee3TzBZiObpMI7bSl9nmiYgrYswbmKnE755wDsn54KK9ZuShqB0UW/FZpABVP
         0NaxY4B3UmGGejEmMxp/nFcd9m+9zAIFoCf5JXlU3/dg76fXoN2Bbnsz6lwsMmi0z1UB
         /UPZA4yT4ijfCa+l7PuDcocHIBiBrVFYQGB5xuUAL85xp42c00Fkqw720t0Dg03ADHEw
         +DAozFShV9jJe0qalCqSMAt8o8l1FrigXVJT+0f9qMLzgzdgq5AIcQywzxVAvWL4aqr8
         edEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1741923204; x=1742528004;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=DYgZCPsa0glvWARJH+pfbMMs+AJ3+XfL5H5kBmyXwJM=;
        b=AY7n8g/0jdhc2jcedJquz1pLgGgAkMemkAdGh+vdOaWajlvwCJT1oIYk79u3Swmd6e
         by+ML8B6yKE23YBRO4+2akdiCqjUDjAMm6XPByieeE79V2gvIplN+6PuV0KlSq2TFe2V
         3MIagR0eDbCgIrDnQuqqvw96XTOueVdpnfB/VjlmV1RmJ+aYuujIWKUiVQTQA4DCo9h3
         B2dKXxZgQa3o+yzGbJX652WB/es93QUB09OrycbUMAm+LVcLZb4OeyZM9orrovS/tced
         QnKd6M9OXmgTF0VStDQrs4ifkTXLR0QGh3yALE+6Y1P5GzSJlvsh36BDNpKNesoNkpoL
         WbZA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCV/S7g3vefZyNEjKyY/HP3+5hQk7kqgSdb1ke2kK7lGIEZ6eQzv/WluAv35Lezn5gUzpaW7YwYMfSx7@gnusha.org
X-Gm-Message-State: AOJu0YxAx9hPcHd75j1U31VaOHy60OKVUnh8/wSORkOdB3ALEHLjmzXX
	ZUE0s4KnGmYilALJBEWPwqMlXTYhUjkwKYv6lMsLMaXtH0SikyvK
X-Google-Smtp-Source: AGHT+IEdFyTinj8F9k7gGNjqQbxXZCqWgJRnTd59u50ZHZArn0lk0hHqDirqBTDzgty/Tkp6jgdVVQ==
X-Received: by 2002:a05:6902:228c:b0:e54:9cb1:21a6 with SMTP id 3f1490d57ef6-e63f64f8162mr1157387276.11.1741923203990;
        Thu, 13 Mar 2025 20:33:23 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPAK2yqu5qy2byqWt/Kkrl3z+SGCWQKhU3DmuEuHa1dxyGw==
Received: by 2002:a25:7ac2:0:b0:e5b:423e:3be6 with SMTP id 3f1490d57ef6-e63dc2c8a09ls1734545276.1.-pod-prod-08-us;
 Thu, 13 Mar 2025 20:33:20 -0700 (PDT)
X-Received: by 2002:a05:6902:1501:b0:e63:3e41:6579 with SMTP id 3f1490d57ef6-e63f65ee09emr1106231276.47.1741923200528;
        Thu, 13 Mar 2025 20:33:20 -0700 (PDT)
Received: by 2002:a05:690c:288a:b0:6fb:b341:b6f6 with SMTP id 00721157ae682-6ff19b1c6f6ms7b3;
        Thu, 13 Mar 2025 05:56:00 -0700 (PDT)
X-Received: by 2002:a05:690c:3003:b0:6fe:c021:f745 with SMTP id 00721157ae682-6fec021f9c3mr264665857b3.4.1741870559405;
        Thu, 13 Mar 2025 05:55:59 -0700 (PDT)
Date: Thu, 13 Mar 2025 05:55:58 -0700 (PDT)
From: Garlo Nicon <garlonicon@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <526eb6e1-ace2-47e9-9259-e2ec74b749b6n@googlegroups.com>
In-Reply-To: <CALQsJZX=6zNc-_b8MjHu-KftjqiJtScLVULCtHeLDNBo_2OQqQ@mail.gmail.com>
References: <62b454f8-56be-4eae-ba3e-57c53d493f3dn@googlegroups.com>
 <w6yVRkZu07vMNHYp483katPNPA5nwFEx-kje8eSpjRl9S6O8rx_ViKi62XlcW2b36SF8dceUXKkBLrmrtvK7RuPd1w1y0iZ4BBP4rSleNcc=@wuille.net>
 <CALQsJZX=6zNc-_b8MjHu-KftjqiJtScLVULCtHeLDNBo_2OQqQ@mail.gmail.com>
Subject: Re: [bitcoindev] Proposal: Unlocking Dust UTXOs as Miner Transaction Fees
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_129772_267449275.1741870558887"
X-Original-Sender: garlonicon@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

------=_Part_129772_267449275.1741870558887
Content-Type: multipart/alternative; 
	boundary="----=_Part_129773_1417507890.1741870558887"

------=_Part_129773_1417507890.1741870558887
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I wonder, why OP used so much of AI-generated content to make these posts.

> What if miners claim authorized dust UTXOs through entirely separate,=20
regular, standard-format transactions?

They can do that today, no changes are needed. Just sign any dust with=20
SIGHASH_NONE | SIGHASH_ANYONECANPAY, or even use SIGHASH_SINGLE bug, to=20
spend all coins from the same public key, with the same signature.

> What if miners are permitted to spend dust UTXOs without their original=
=20
conditions only under strictly defined new rules

Then it is still a hard-fork. But your AI model probably cannot understand=
=20
it.

niedziela, 9 marca 2025 o 02:43:29 UTC+1 Nighttime Satoshi napisa=C5=82(a):

> Hi Pieter,
>
> You're absolutely right. You've raised valid technical concerns about my=
=20
> original proposal regarding coinbase limitations and soft fork=20
> requirements. Based on your points, I've reconsidered the implementation=
=20
> approach to ensure it works as a proper soft fork. Here's the revised=20
> mechanism. I'm curious to hear your thoughts:
>
> The basic premise is that dust UTXOs are a deadweight loss to the Bitcoin=
=20
> Network - and we must find a solution at the L1 level that can "revive"=
=20
> these dust satoshis back into the network at their full value, in order t=
o=20
> improve Bitcoin's fungibility. This dust problem will only get more=20
> significant, and I don't think the deflationary effect of lost satoshis i=
s=20
> more valuable than the prospect of full fungibility. L2 solutions are a=
=20
> bandaid.=20
>
> *Amendments*:
>
>
> *1. Coinbase Transaction Inputs:*
> *Concern*: Coinbase transactions can only have exactly one input.=20
> Allowing coinbase transactions to spend additional outputs would require =
a=20
> hard fork.
>
> *Revised Solution:* What if miners claim authorized dust UTXOs through=20
> entirely separate, regular, standard-format transactions? Though not=20
> economically feasible for single transactions, it becomes extremely=20
> beneficial economically when batching multiple dust UTXOs simultaneously,=
=20
> significantly amortizing transaction overhead across many claims. Coinbas=
e=20
> transactions remain exactly as they are today, retaining their single-inp=
ut=20
> rule and current consensus constraints.
>
> *2. Spending Dust Outputs Without Original Conditions*
>
> *Concern: *The dust outputs marked for claiming by miners can't currently=
=20
> be spent without fulfilling their original conditions, which would requir=
e=20
> a hard fork to change.
>
> *Revised Solution:* What if miners are permitted to spend dust UTXOs=20
> without their original conditions *only under strictly defined new rules:=
*
>
> ** *The dust UTXO must be explicitly authorized for miner spending=20
> through an OP_RETURN-based "Dust Fee Authorization" (DFA) transaction.
>
> *The miner=E2=80=99s transaction claiming this dust must occur in the exa=
ct same=20
> block as the DFA transaction.
>
> *Only dust UTXOs below a clearly defined threshold (546 sats) are eligibl=
e.
>
> These new consensus rules *strictly restrict* previously impossible=20
> spending conditions, making it unequivocally a valid soft fork. No=20
> previously illegal behavior is permitted without new restrictive conditio=
ns=20
> explicitly met.
>
>
> *3. Economic and Practical Viability*
>
> *Concern: *The economic overhead (OP_RETURN transaction plus coinbase=20
> input overhead) might be larger than simply spending the dust normally.
>
> *Revised Solution:* With coinbase inputs no longer altered, the overhead=
=20
> is significantly reduced. Furthermore, the revised mechanism explicitly=
=20
> encourages batching multiple dust authorizations into a single DFA=20
> transaction, dramatically amortizing overhead costs across many dust UTXO=
s.=20
> This batching substantially improves economic viability, especially durin=
g=20
> periods of lower mempool congestion where fees are minimal.
>
> Does this design address your concerns while preserving the original goal=
=20
> of voluntary, secure, and economically rational reclamation of dust UTXOs=
?
>
> Your insights have been invaluable. I'm eager to receive any further=20
> feedback on this revised design.
>
> Thank you again for your careful review and helpful critique.
>
> Best regards,
>
> On Sat, Mar 8, 2025 at 5:49=E2=80=AFPM Pieter Wuille <bitco...@wuille.net=
> wrote:
>
>> Hello,
>>
>> This is not a soft fork, for two reasons:
>>
>> * Coinbase transactions can only have exactly one input. I don't think=
=20
>> there is a particularly good reason for this besides simplicity, but tha=
t=20
>> is the current rule. Allowing a coinbase transaction to additionally als=
o=20
>> spend certain outputs would require a hardfork.
>>
>> * The outputs being marked as dust are not allowed to be spent by miners=
.=20
>> Changing this requires a hardfork as well. Think about it: if this was=
=20
>> possible with a softfork, it must mean that doing what you're proposing=
=20
>> would *already be legal* today, and thus not need this proposed change i=
n=20
>> the first place. Softforks can only outlaw formerly legal behavior.
>>
>> Furthermore, I don't really see the point. The proposal requires both a=
=20
>> coinbase txin to spend the coin, plus a signature in a separate=20
>> transaction, in the same block. To pay the miner for the opportunity cos=
t=20
>> of not including normal transactions with these bytes, the fee for this=
=20
>> OP_RETURN output should economically be priced at the block's feerate fo=
r=20
>> the size of the OP_RETURN output *plus* the cost of the coinbase=20
>> transaction input. Together, they are no smaller (and with witness=20
>> discount, I suspect larger) than the user just spending their "dust"=20
>> output, and thus the fee for using this OP_RETURN-based mechanism would =
be=20
>> larger than the value of the dust output.
>>
>> --=20
>> Pieter
>>
>> On Saturday, March 8th, 2025 at 1:23 PM, Nighttime Satoshi <
>> nighttim...@gmail.com> wrote:
>>
>> > Dear fellow Bitcoin developers,
>> >=20
>> > I'm excited to share a proposal addressing a long-standing Bitcoin=20
>> challenge: economically unviable dust UTXOs.
>>
>>

--=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/=
526eb6e1-ace2-47e9-9259-e2ec74b749b6n%40googlegroups.com.

------=_Part_129773_1417507890.1741870558887
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I wonder, why OP used so much of AI-generated content to make these posts.<=
br /><br />&gt; What if miners claim authorized dust UTXOs through entirely=
 separate, regular, standard-format transactions?<br /><br />They can do th=
at today, no changes are needed. Just sign any dust with SIGHASH_NONE | SIG=
HASH_ANYONECANPAY, or even use SIGHASH_SINGLE bug, to spend all coins from =
the same public key, with the same signature.<br /><br />&gt; What if miner=
s are permitted to spend dust UTXOs without their original conditions only =
under strictly defined new rules<br /><br />Then it is still a hard-fork. B=
ut your AI model probably cannot understand it.<br /><br /><div class=3D"gm=
ail_quote"><div dir=3D"auto" class=3D"gmail_attr">niedziela, 9 marca 2025 o=
=C2=A002:43:29 UTC+1 Nighttime Satoshi napisa=C5=82(a):<br/></div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-left: 1px sol=
id rgb(204, 204, 204); padding-left: 1ex;"><div dir=3D"ltr">Hi Pieter,<div>=
<br></div><div>You&#39;re absolutely right. You&#39;ve raised valid technic=
al concerns about my original proposal regarding coinbase limitations and s=
oft fork requirements. Based on your points, I&#39;ve reconsidered the impl=
ementation approach to ensure it works as a proper soft fork. Here&#39;s th=
e revised mechanism. I&#39;m curious to hear your thoughts:</div><div><br><=
/div><div>The basic premise is that dust UTXOs are a deadweight loss to the=
 Bitcoin Network - and we must find a solution at the L1 level that can &qu=
ot;revive&quot; these dust satoshis back into the network at their full val=
ue, in order to improve Bitcoin&#39;s fungibility. This dust problem will o=
nly get more significant, and I don&#39;t think the deflationary effect of =
lost satoshis is more valuable than the prospect of full fungibility. L2 so=
lutions are a bandaid.=C2=A0<br><br><b>Amendments</b>:</div><div><b><br></b=
></div><div><b>1. Coinbase Transaction Inputs:<br></b><strong style=3D"colo=
r:rgb(0,0,0)"><br></strong></div><div><span style=3D"color:rgb(0,0,0)"><b>C=
oncern</b>:=C2=A0</span><span style=3D"color:rgb(0,0,0)">Coinbase transacti=
ons can only have exactly one input. Allowing coinbase transactions to spen=
d additional outputs would require a hard fork.</span><br></div><div><p sty=
le=3D"color:rgb(0,0,0)"><strong>Revised Solution:</strong><span>=C2=A0</spa=
n>What if miners claim authorized dust UTXOs through entirely separate, reg=
ular, standard-format transactions? Though not economically=C2=A0feasible f=
or single transactions, it becomes extremely beneficial economically when b=
atching multiple dust UTXOs simultaneously, significantly amortizing transa=
ction overhead across many claims. Coinbase transactions remain exactly as =
they are today, retaining their single-input rule and current consensus con=
straints.</p><p style=3D"color:rgb(0,0,0)"><b>2. Spending Dust Outputs With=
out Original Conditions</b></p><p style=3D"color:rgb(0,0,0)"><strong>Concer=
n:=C2=A0</strong>The dust outputs marked for claiming by miners can&#39;t c=
urrently be spent without fulfilling their original conditions, which would=
 require a hard fork to change.</p><p style=3D"color:rgb(0,0,0)"><strong>Re=
vised Solution:</strong><span>=C2=A0</span>What if miners are permitted to =
spend dust UTXOs without their original conditions<span>=C2=A0</span><stron=
g>only under strictly defined new rules:</strong></p><p style=3D"color:rgb(=
0,0,0)"><b>*=C2=A0</b>The dust UTXO must be explicitly authorized for miner=
 spending through an OP_RETURN-based &quot;Dust Fee Authorization&quot; (DF=
A) transaction.</p><p style=3D"color:rgb(0,0,0)">*The miner=E2=80=99s trans=
action claiming this dust must occur in the exact same block as the DFA tra=
nsaction.</p><p style=3D"color:rgb(0,0,0)">*Only dust UTXOs below a clearly=
 defined threshold (546 sats) are eligible.</p><p style=3D"color:rgb(0,0,0)=
">These new consensus rules<span>=C2=A0</span><strong>strictly restrict</st=
rong><span>=C2=A0</span>previously impossible spending conditions, making i=
t unequivocally a valid soft fork. No previously illegal behavior is permit=
ted without new restrictive conditions explicitly met.</p><p style=3D"color=
:rgb(0,0,0)"><b>3. Economic and Practical Viability<br></b></p><p style=3D"=
color:rgb(0,0,0)"><strong>Concern:=C2=A0</strong>The economic overhead (OP_=
RETURN transaction plus coinbase input overhead) might be larger than simpl=
y spending the dust normally.</p><p style=3D"color:rgb(0,0,0)"><strong>Revi=
sed Solution:</strong><span>=C2=A0</span>With coinbase inputs no longer alt=
ered, the overhead is significantly reduced. Furthermore, the revised mecha=
nism explicitly encourages batching multiple dust authorizations into a sin=
gle DFA transaction, dramatically amortizing overhead costs across many dus=
t UTXOs. This batching substantially improves economic viability, especiall=
y during periods of lower mempool congestion where fees are minimal.</p><p =
style=3D"color:rgb(0,0,0)">Does this design=C2=A0address your concerns whil=
e preserving the original goal of voluntary, secure, and economically ratio=
nal reclamation of dust UTXOs?<br></p><p style=3D"color:rgb(0,0,0)">Your in=
sights have been invaluable. I&#39;m eager to receive any further feedback =
on this revised design.</p><p style=3D"color:rgb(0,0,0)">Thank you again fo=
r your careful review and helpful critique.</p><p style=3D"color:rgb(0,0,0)=
">Best regards,</p></div></div><br><div class=3D"gmail_quote"><div dir=3D"l=
tr" class=3D"gmail_attr">On Sat, Mar 8, 2025 at 5:49=E2=80=AFPM Pieter Wuil=
le &lt;<a href data-email-masked rel=3D"nofollow">bitco...@wuille.net</a>&g=
t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color=
:rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
This is not a soft fork, for two reasons:<br>
<br>
* Coinbase transactions can only have exactly one input. I don&#39;t think =
there is a particularly good reason for this besides simplicity, but that i=
s the current rule. Allowing a coinbase transaction to additionally also sp=
end certain outputs would require a hardfork.<br>
<br>
* The outputs being marked as dust are not allowed to be spent by miners. C=
hanging this requires a hardfork as well. Think about it: if this was possi=
ble with a softfork, it must mean that doing what you&#39;re proposing woul=
d *already be legal* today, and thus not need this proposed change in the f=
irst place. Softforks can only outlaw formerly legal behavior.<br>
<br>
Furthermore, I don&#39;t really see the point. The proposal requires both a=
 coinbase txin to spend the coin, plus a signature in a separate transactio=
n, in the same block. To pay the miner for the opportunity cost of not incl=
uding normal transactions with these bytes, the fee for this OP_RETURN outp=
ut should economically be priced at the block&#39;s feerate for the size of=
 the OP_RETURN output *plus* the cost of the coinbase transaction input. To=
gether, they are no smaller (and with witness discount, I suspect larger) t=
han the user just spending their &quot;dust&quot; output, and thus the fee =
for using this OP_RETURN-based mechanism would be larger than the value of =
the dust output.<br>
<br>
-- <br>
Pieter<br>
<br>
On Saturday, March 8th, 2025 at 1:23 PM, Nighttime Satoshi &lt;<a href data=
-email-masked rel=3D"nofollow">nighttim...@gmail.com</a>&gt; wrote:<br>
<br>
&gt; Dear fellow Bitcoin developers,<br>
&gt; <br>
&gt; I&#39;m excited to share a proposal addressing a long-standing Bitcoin=
 challenge: economically unviable dust UTXOs.<br>
<br>
</blockquote></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/526eb6e1-ace2-47e9-9259-e2ec74b749b6n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/526eb6e1-ace2-47e9-9259-e2ec74b749b6n%40googlegroups.com</a>.<br />

------=_Part_129773_1417507890.1741870558887--

------=_Part_129772_267449275.1741870558887--