path: root/28/0dba498289e7c103dd4387363fa091e82c73be

Return-Path: <leohaf@orangepill.ovh>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 8009AC0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  3 Aug 2023 16:03:48 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 53027408F2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  3 Aug 2023 16:03:48 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 53027408F2
Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key,
 unprotected) header.d=orangepill.ovh header.i=@orangepill.ovh
 header.a=rsa-sha256 header.s=sig1 header.b=Sy/cqdoh
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.787
X-Spam-Level: 
X-Spam-Status: No, score=-2.787 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001,
 RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
 T_MIME_MALF=0.01] autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id xNCuQVX6pj5F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  3 Aug 2023 16:03:45 +0000 (UTC)
Received: from st43p00im-zteg10061901.me.com (st43p00im-zteg10061901.me.com
 [17.58.63.168])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 4EF6C408CE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  3 Aug 2023 16:03:45 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 4EF6C408CE
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orangepill.ovh;
 s=sig1; t=1691078623;
 bh=3ikszm30PJ6ciz2LS3E/TY3i+09uaAgf8jvAH6ox8I4=;
 h=From:Content-Type:Mime-Version:Subject:Date:To:Message-Id;
 b=Sy/cqdohWA1fd10I46ObzzzJ6QqzzoG9CWwdG7j9jzU1KAbsqNcjde6WmMq6zu6NL
 JiUlOJfMMWUSEaaLMfNEXIhcdHKBOfdd/Wd2qf3lh/M5crTUPhXyGNi8O5WldA3Omj
 A8bSp3E0dzbeSq+XLaWsVwxkiNKOeCbk9NXR2wryALc2eCCkmwrd45djU6O6qLyExf
 tGrRXRsQizyWbayIdGlby3u6t6ZrXq7stS7ORDcUR891toDjRDvbVlTpR3V6ofAMtp
 YiZDJxhHX/2cxnQbL3KHmZtLLOStfdp7vPtNj74A1/AygK/sWQfOthYQwVcJ/mlzZu
 obSB4FhwtfPsA==
Received: from smtpclient.apple (st43p00im-dlb-asmtp-mailmevip.me.com
 [17.42.251.41])
 by st43p00im-zteg10061901.me.com (Postfix) with ESMTPSA id 26F665403F3;
 Thu,  3 Aug 2023 16:03:39 +0000 (UTC)
From: leohaf@orangepill.ovh
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_A96D14F8-1620-4272-BB9D-EABD8E30F61E"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
Date: Thu, 3 Aug 2023 18:03:27 +0200
References: <CAJCwDN8gLwSG+y1gMD37TrbYvi7M+q6ub3Eamx3wzQqVbatJDw@mail.gmail.com>
To: GamedevAlice <gamedevalice256@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAJCwDN8gLwSG+y1gMD37TrbYvi7M+q6ub3Eamx3wzQqVbatJDw@mail.gmail.com>
Message-Id: <16B6864A-BE97-405B-B4B8-2086ECDBDA2B@orangepill.ovh>
X-Mailer: Apple Mail (2.3731.700.6)
X-Proofpoint-GUID: 1FdMcxReKigDdMkdF6h4Nv4U2Ke7t2SN
X-Proofpoint-ORIG-GUID: 1FdMcxReKigDdMkdF6h4Nv4U2Ke7t2SN
X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?=
 =?UTF-8?Q?2903e8d5c8f:6.0.573,18.0.572,17.0.605.474.0000000_definitions?=
 =?UTF-8?Q?=3D2023-05-17=5F02:2023-05-17=5F02,2020-02-14=5F11,2020-01-23?=
 =?UTF-8?Q?=5F02_signatures=3D0?=
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999
 suspectscore=0
 phishscore=0 clxscore=1030 malwarescore=0 mlxscore=0 spamscore=0
 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2212070000 definitions=main-2308030144
X-Mailman-Approved-At: Thu, 03 Aug 2023 17:36:47 +0000
Subject: Re: [bitcoin-dev] Concern about "Inscriptions".
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Aug 2023 16:03:48 -0000


--Apple-Mail=_A96D14F8-1620-4272-BB9D-EABD8E30F61E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Utreexo only seems to save us time if it is used in "bridge" mode =
otherwise it takes soft fork for all nodes to use Utreexo at the price =
of larger transaction.

The problem is not here for the moment, it is imperative to solve the =
problem of inscription that quickly brings us closer to the need for =
Utreexo.

> Le 3 ao=C3=BBt 2023 =C3=A0 15:33, GamedevAlice via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :
>=20
> After looking into this more deeply (thanks to Luke Dashjr for =
pointing me in the right direction) it is now clear to me that storage =
isn't the real issue, but rather the "initial blockchain sync" time - in =
which storage certainly has a significant role to play, at least =
currently.=20
>=20
> At the moment, UTreeXO seems like a promising first step. Perhaps =
there is a more efficient way to sync the chain without having to =
download everything and while still verifying it trustlessly.=20
>=20
>=20
>=20
> On Thu, Aug 3, 2023, 7:43 AM , =
<bitcoin-dev-request@lists.linuxfoundation.org =
<mailto:bitcoin-dev-request@lists.linuxfoundation.org>> wrote:
>> Send bitcoin-dev mailing list submissions to
>>         bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>
>>=20
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         =
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> or, via email, send a message with subject or body 'help' to
>>         bitcoin-dev-request@lists.linuxfoundation.org =
<mailto:bitcoin-dev-request@lists.linuxfoundation.org>
>>=20
>> You can reach the person managing the list at
>>         bitcoin-dev-owner@lists.linuxfoundation.org =
<mailto:bitcoin-dev-owner@lists.linuxfoundation.org>
>>=20
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of bitcoin-dev digest..."
>>=20
>>=20
>> Today's Topics:
>>=20
>>    1. Re: Concern about "Inscriptions". (Keagan McClelland) =
(Einherjar)
>>    2. Re: Pull-req to enable Full-RBF by default (Daniel Lipshitz)
>>    3. Pull-req to remove the arbitrary limits on OP_Return      =
outputs
>>       (Peter Todd)
>>=20
>>=20
>> =
----------------------------------------------------------------------
>>=20
>> Message: 1
>> Date: Wed, 02 Aug 2023 13:50:30 +0000
>> From: Einherjar <realeinherjar@proton.me =
<mailto:realeinherjar@proton.me>>
>> To: bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>, Keagan McClelland
>>         <keagan.mcclelland@gmail.com =
<mailto:keagan.mcclelland@gmail.com>>
>> Subject: Re: [bitcoin-dev] Concern about "Inscriptions". (Keagan
>>         McClelland)
>> Message-ID:
>>         =
<EGcuw9I68gwGmFMMw_OstpvAHQ0sWleUi3Jfa8t9A14fa5PGYR2EAxJIjwKd8jo5JtUfmyw9t=
aF1qEsQlVoXBpLUxixdlBpIOEhuXzTUSEc=3D@proton.me <http://proton.me/>>
>>=20
>> Content-Type: text/plain; charset=3D"utf-8"
>>=20
>> About price space in the UTXO set:
>>=20
>> I am highly concerned with that proposal.
>> The reason is this could restrict users to do proper UTXO management =
and lead to doxing and privacy issues. Now there are few costs =
associated to having lots of UTXOs, mainly fees associated with spending =
low-valued UTXOs.
>>=20
>> > There is an open question as to whether or not we should figure out =
a way
>> > to price space in the UTXO set. I think it is fair to say that =
given the
>> > fact that the UTXO set space remains unpriced that we actually have =
no way
>> > to determine whether some of these transactions are spam or not. =
The UTXO
>> > set must be maintained by all nodes including pruned nodes, whereas =
main
>> > block and witness data do not have the same type of indefinite =
footprint,
>> > so in some sense it is an even more significant resource than chain =
space.
>> > We may very well discover that if we price UTXOs in a way that =
reflect the
>> > resource costs that usage of inscriptions would vanish. The trouble =
though
>> > is that such a mechanism would imply having to pay "rent" for an =
"account"
>> > with Bitcoin, a proposition that would likely be offensive to a =
significant
>> > portion of the Bitcoin user base.
>> >=20
>>=20
>> > Cheers,
>> > Keags
>>=20
>>=20
>> Einherjar - E7ED 7E35 F072 CA83
>>=20
>> Sent with Proton Mail secure email.
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: publickey - realeinherjar@proton.me =
<mailto:realeinherjar@proton.me> - 0xBF60A699.asc
>> Type: application/pgp-keys
>> Size: 657 bytes
>> Desc: not available
>> URL: =
<http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/202308=
02/cf726d41/attachment-0001.bin>
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: signature.asc
>> Type: application/pgp-signature
>> Size: 249 bytes
>> Desc: OpenPGP digital signature
>> URL: =
<http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/202308=
02/cf726d41/attachment-0001.sig>
>>=20
>> ------------------------------
>>=20
>> Message: 2
>> Date: Wed, 2 Aug 2023 18:29:54 +0300
>> From: Daniel Lipshitz <daniel@gap600.com <mailto:daniel@gap600.com>>
>> To: Peter Todd <pete@petertodd.org <mailto:pete@petertodd.org>>
>> Cc: Bitcoin Protocol Discussion
>>         <bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>>
>> Subject: Re: [bitcoin-dev] Pull-req to enable Full-RBF by default
>> Message-ID:
>>         =
<CACkWPs_jKUCBPhvj3mGYQu6erLE5qKxXorXAtJpuGCKSaSjVwQ@mail.gmail.com =
<mailto:CACkWPs_jKUCBPhvj3mGYQu6erLE5qKxXorXAtJpuGCKSaSjVwQ@mail.gmail.com=
>>
>> Content-Type: text/plain; charset=3D"utf-8"
>>=20
>> For clarity purposes.
>>=20
>>    1. Our research is based on monitoring main net transactions and =
network
>>    activity - as too is our risk engine. We do not engage in specific =
hashing
>>    pool assessments or research.
>>    2. It is not easily possible or comfortable to engage with our =
clients
>>    to offer up their client names and applications - the competition =
is fierce
>>    and like other industries it is not an acceptable approach to ask.
>>    3. The information offered by Coinpaid and posted on this list, =
provides
>>    root addresses which using tools like Chainanlysis, or
>>    similar service providers can confirm these addresses are =
associated with
>>    Coinspaid. This can validate a significant amount of our traffic.
>>    4. Based on the information provided it will be very possible to =
reach
>>    out to Max at Coinpaid - and will be able to confirm GAP600 use =
with
>>    Coinspaid. This is in addition to me posting an email from Max =
back in Dec
>>    2022 to this list confirming all of this information.
>>    5.  It is more than likely that Changelly has not implemented our
>>    service across all irts offerings, a large section of their =
business is
>>    servicing partners.
>>=20
>> ________________________________
>>=20
>> Daniel Lipshitz
>> GAP600| www.gap600.com <http://www.gap600.com/>
>> Phone: +44 113 4900 117
>> Skype: daniellipshitz123
>> Twitter: @daniellipshitz
>>=20
>>=20
>> On Wed, Aug 2, 2023 at 1:38?PM Daniel Lipshitz <daniel@gap600.com =
<mailto:daniel@gap600.com>> wrote:
>>=20
>> > Your assessment of my dishonesty is based on your assumption of how =
I
>> > should be running GAP600, your assumptions are baseless and lack =
commercial
>> > experience and likewise your conclusions are false.
>> >
>> > I have provided already back in December clear access to clarify =
opposite
>> > our clients corroborated with easily verifiable trxs activity of a =
major
>> > client of ours. This is more than enough to corroborate our =
statistics.
>> >
>> > As far as validating real RBF adoption I have offered a clear =
option here
>> > =
https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1661960440
>> > something like this or similar would offer a clear assessment of =
adoption.
>> > Since you are not able to provide documents or public emails of =
hashing
>> > pools confirming there adoption of Full RBF.
>> > ________________________________
>> >
>> > Daniel Lipshitz
>> > GAP600| www.gap600.com <http://www.gap600.com/>
>> > Phone: +44 113 4900 117
>> > Skype: daniellipshitz123
>> > Twitter: @daniellipshitz
>> >
>> >
>> > On Wed, Aug 2, 2023 at 4:28?AM Peter Todd <pete@petertodd.org =
<mailto:pete@petertodd.org>> wrote:
>> >
>> >> On Wed, Aug 02, 2023 at 01:27:24AM +0300, Daniel Lipshitz wrote:
>> >> > Your research is not thorough and reaches an incorrect =
conclusion.
>> >> >
>> >> > As stated many times - we service payment processors and some =
merchants
>> >> > directly  - Coinspaid services multiple merchants and process a
>> >> > significant amount of BTC they are a well known and active in =
the space
>> >> -
>> >> > as I provided back in December 2022 a email from Max the CEO of
>> >> Coinspaid
>> >> > confirming their use of 0-conf as well as providing there =
cluster
>> >> addresses
>> >> > to validate there deposit flows see here again -
>> >> >
>> >> =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/0212=
39.html
>> >> > - if this is not sufficient then please email =
support@coinspaid.com <mailto:support@coinspaid.com>
>> >> and ask
>> >> > to be connected to Max or someone from the team who can confirm
>> >> Conspaid is
>> >> > clients of GAP600. Max also at the time was open to do a call, I =
can
>> >> check
>> >> > again now and see if this is still the case and connect you.
>> >> >
>> >> > That on its own is enough of a sample to validate our =
statistics.
>> >>
>> >> Why don't you just give me an example of some merchants using =
Coinspaid,
>> >> and
>> >> another example using Coinpayments, who rely on unconfirmed =
transactions?
>> >> If
>> >> those merchants actually exist it should be very easy to give me =
some
>> >> names of
>> >> them.
>> >>
>> >> Without actual concrete examples for everyone to see for =
themselves, why
>> >> should
>> >> we believe you?
>> >>
>> >> > I have also spoken to Changelly earlier today and they offered =
to email
>> >> pro
>> >> > @ changelly.com <http://changelly.com/> and they will be able to =
confirm GAP600 as a service
>> >>
>> >> Emailed; waiting on a reply.
>> >>
>> >> > provider. Also please send me the 1 trx hash you tested and I =
can see
>> >> if it
>> >> > was queried to our system and if so offer some info as to why it =
wasnt
>> >> > approved. Also if you can elaborate how you integrated with =
Changelly -
>> >> I
>> >> > can check with them if that area is not integrated with GAP600.
>> >>
>> >> Why don't you just tell me exactly what service Changelly offers =
that
>> >> relies on
>> >> unconfirmed transactions, and what characteristics would meet =
GAP600's
>> >> risk
>> >> criteria? I and others on this mailing list could easily do test
>> >> transactions
>> >> if you told us what we can actually test. If your service actually =
works,
>> >> then
>> >> you can safely provide that information.
>> >>
>> >> I'm not going to give you any exact tx hashes of transactions I've =
already
>> >> done, as I don't want to cause any problems for the owners of the
>> >> accounts I
>> >> borrowed for testing. Given your lack of honesty so far I have =
every
>> >> reason to
>> >> believe they might be retalliated against in some way.
>> >>
>> >> > As the architect of such a major change to the status of 0-conf
>> >> > transactions I would think you would welcome the opportunity to =
speak to
>> >> > business and users who actual activities will be impacted by =
full RBF
>> >> > becoming dominant.
>> >>
>> >> Funny how you say this, without actually giving any concrete =
examples of
>> >> businesses that will be affected. Who exactly are these =
businesses?
>> >> Payment
>> >> processors obviously don't count.
>> >>
>> >> > Are you able to provide the same i.e emails and contacts of =
people at
>> >> > the mining pools who can confirm they have adopted FULL RBF ?
>> >>
>> >> I've already had multiple mining pools complain to me that they =
and their
>> >> employees have been harassed over full-rbf, so obviously I'm not =
going to
>> >> provide you with any private contact information I have. There's =
no need
>> >> to
>> >> expose them to further harassment.
>> >>
>> >> If you actually offered an unconfirmed transaction guarantee =
service,
>> >> with real
>> >> customers getting an actual benefit, you'd be doing test =
transactions
>> >> frequently and would already have a very good idea of what pools =
do
>> >> full-rbf.
>> >> Why don't you already have this data?
>> >>
>> >> --
>> >> https://petertodd.org <https://petertodd.org/> =
'peter'[:-1]@petertodd.org <http://petertodd.org/>
>> >>
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: =
<http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/202308=
02/06762493/attachment-0001.html>
>>=20
>> ------------------------------
>>=20
>> Message: 3
>> Date: Thu, 3 Aug 2023 11:42:40 +0000
>> From: Peter Todd <pete@petertodd.org <mailto:pete@petertodd.org>>
>> To: bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>
>> Subject: [bitcoin-dev] Pull-req to remove the arbitrary limits on
>>         OP_Return       outputs
>> Message-ID: <ZMuSsBkWqVXO9qoN@petertodd.org =
<mailto:ZMuSsBkWqVXO9qoN@petertodd.org>>
>> Content-Type: text/plain; charset=3D"us-ascii"
>>=20
>> https://github.com/bitcoin/bitcoin/pull/28130
>>=20
>> Sjors Provoost suggested that I email this mailing list as notice of =
my intent
>> to get a pull-req merged that would remove the arbitrary 80-byte, 1 =
output /
>> tx, standardness restrictions on OP_Return outputs. His rationale was =
that
>> removing these standardness restrictions could potentially open up =
additional
>> transaction pinning(1) vectors. Since this is a potential problem =
with any
>> relaxation of standardness rules, I don't consider this to be an =
important
>> concern. But consider this email your notice.
>>=20
>> At least some miners appear to be mining non-bitcoin-core-standard
>> transactions. So with respect to the hash power of those miners these =
pinning
>> vectors may in fact exist already.
>>=20
>>=20
>> # References
>>=20
>> 1) https://bitcoinops.org/en/topics/transaction-pinning/
>>=20
>> --=20
>> https://petertodd.org <https://petertodd.org/> =
'peter'[:-1]@petertodd.org <http://petertodd.org/>
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: signature.asc
>> Type: application/pgp-signature
>> Size: 833 bytes
>> Desc: not available
>> URL: =
<http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/202308=
03/33786fbc/attachment.sig>
>>=20
>> ------------------------------
>>=20
>> Subject: Digest Footer
>>=20
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>=20
>>=20
>> ------------------------------
>>=20
>> End of bitcoin-dev Digest, Vol 99, Issue 6
>> ******************************************
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--Apple-Mail=_A96D14F8-1620-4272-BB9D-EABD8E30F61E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;"><div>Utreexo =
only seems to save us time if it is used in "bridge" mode otherwise it =
takes soft fork for all nodes to use Utreexo at the price of larger =
transaction.</div><div><br></div><div>The problem is not here for the =
moment, it is imperative to solve the problem of inscription that =
quickly brings us closer to the need for =
Utreexo.</div><div><br></div><div><div><blockquote type=3D"cite"><div>Le =
3 ao=C3=BBt 2023 =C3=A0 15:33, GamedevAlice via bitcoin-dev =
&lt;bitcoin-dev@lists.linuxfoundation.org&gt; a =C3=A9crit :</div><br =
class=3D"Apple-interchange-newline"><div><div dir=3D"auto"><div =
dir=3D"auto">After looking into this more deeply (thanks to Luke Dashjr =
for pointing me in the right direction) it is now clear to me that =
storage isn't the real issue, but rather the "initial blockchain sync" =
time - in which storage certainly has a significant role to play, at =
least currently.&nbsp;</div><div dir=3D"auto"><br></div><div =
dir=3D"auto">At the moment, UTreeXO seems like a promising first step. =
Perhaps there is a more efficient way to sync the chain without having =
to download everything and while still verifying it =
trustlessly.&nbsp;</div><div dir=3D"auto"><br></div><div =
dir=3D"auto"><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">On Thu, Aug 3, 2023, 7:43 AM , &lt;<a =
href=3D"mailto:bitcoin-dev-request@lists.linuxfoundation.org" =
rel=3D"noreferrer noreferrer" =
target=3D"_blank">bitcoin-dev-request@lists.linuxfoundation.org</a>&gt; =
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">Send bitcoin-dev =
mailing list submissions to<br>
&nbsp; &nbsp; &nbsp; &nbsp; <a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer =
noreferrer noreferrer" =
target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
&nbsp; &nbsp; &nbsp; &nbsp; <a =
href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer noreferrer noreferrer" =
target=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitco=
in-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
&nbsp; &nbsp; &nbsp; &nbsp; <a =
href=3D"mailto:bitcoin-dev-request@lists.linuxfoundation.org" =
rel=3D"noreferrer noreferrer noreferrer" =
target=3D"_blank">bitcoin-dev-request@lists.linuxfoundation.org</a><br>
<br>
You can reach the person managing the list at<br>
&nbsp; &nbsp; &nbsp; &nbsp; <a =
href=3D"mailto:bitcoin-dev-owner@lists.linuxfoundation.org" =
rel=3D"noreferrer noreferrer noreferrer" =
target=3D"_blank">bitcoin-dev-owner@lists.linuxfoundation.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of bitcoin-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
&nbsp; &nbsp;1. Re: Concern about "Inscriptions". (Keagan McClelland) =
(Einherjar)<br>
&nbsp; &nbsp;2. Re: Pull-req to enable Full-RBF by default (Daniel =
Lipshitz)<br>
&nbsp; &nbsp;3. Pull-req to remove the arbitrary limits on =
OP_Return&nbsp; &nbsp; &nbsp; outputs<br>
&nbsp; &nbsp; &nbsp; (Peter Todd)<br>
<br>
<br>
=
----------------------------------------------------------------------<br>=

<br>
Message: 1<br>
Date: Wed, 02 Aug 2023 13:50:30 +0000<br>
From: Einherjar &lt;<a href=3D"mailto:realeinherjar@proton.me" =
rel=3D"noreferrer noreferrer noreferrer" =
target=3D"_blank">realeinherjar@proton.me</a>&gt;<br>
To: <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
rel=3D"noreferrer noreferrer noreferrer" =
target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>, Keagan =
McClelland<br>
&nbsp; &nbsp; &nbsp; &nbsp; &lt;<a =
href=3D"mailto:keagan.mcclelland@gmail.com" rel=3D"noreferrer noreferrer =
noreferrer" target=3D"_blank">keagan.mcclelland@gmail.com</a>&gt;<br>
Subject: Re: [bitcoin-dev] Concern about "Inscriptions". (Keagan<br>
&nbsp; &nbsp; &nbsp; &nbsp; McClelland)<br>
Message-ID:<br>
&nbsp; &nbsp; &nbsp; &nbsp; =
&lt;EGcuw9I68gwGmFMMw_OstpvAHQ0sWleUi3Jfa8t9A14fa5PGYR2EAxJIjwKd8jo5JtUfmy=
w9taF1qEsQlVoXBpLUxixdlBpIOEhuXzTUSEc=3D@<a href=3D"http://proton.me/" =
rel=3D"noreferrer noreferrer noreferrer noreferrer" =
target=3D"_blank">proton.me</a>&gt;<br>
<br>
Content-Type: text/plain; charset=3D"utf-8"<br>
<br>
About price space in the UTXO set:<br>
<br>
I am highly concerned with that proposal.<br>
The reason is this could restrict users to do proper UTXO management and =
lead to doxing and privacy issues. Now there are few costs associated to =
having lots of UTXOs, mainly fees associated with spending low-valued =
UTXOs.<br>
<br>
&gt; There is an open question as to whether or not we should figure out =
a way<br>
&gt; to price space in the UTXO set. I think it is fair to say that =
given the<br>
&gt; fact that the UTXO set space remains unpriced that we actually have =
no way<br>
&gt; to determine whether some of these transactions are spam or not. =
The UTXO<br>
&gt; set must be maintained by all nodes including pruned nodes, whereas =
main<br>
&gt; block and witness data do not have the same type of indefinite =
footprint,<br>
&gt; so in some sense it is an even more significant resource than chain =
space.<br>
&gt; We may very well discover that if we price UTXOs in a way that =
reflect the<br>
&gt; resource costs that usage of inscriptions would vanish. The trouble =
though<br>
&gt; is that such a mechanism would imply having to pay "rent" for an =
"account"<br>
&gt; with Bitcoin, a proposition that would likely be offensive to a =
significant<br>
&gt; portion of the Bitcoin user base.<br>
&gt; <br>
<br>
&gt; Cheers,<br>
&gt; Keags<br>
<br>
<br>
Einherjar - E7ED 7E35 F072 CA83<br>
<br>
Sent with Proton Mail secure email.<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: publickey - <a href=3D"mailto:realeinherjar@proton.me" =
rel=3D"noreferrer noreferrer noreferrer" =
target=3D"_blank">realeinherjar@proton.me</a> - 0xBF60A699.asc<br>
Type: application/pgp-keys<br>
Size: 657 bytes<br>
Desc: not available<br>
URL: &lt;<a =
href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments=
/20230802/cf726d41/attachment-0001.bin" rel=3D"noreferrer noreferrer =
noreferrer noreferrer" =
target=3D"_blank">http://lists.linuxfoundation.org/pipermail/bitcoin-dev/a=
ttachments/20230802/cf726d41/attachment-0001.bin</a>&gt;<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 249 bytes<br>
Desc: OpenPGP digital signature<br>
URL: &lt;<a =
href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments=
/20230802/cf726d41/attachment-0001.sig" rel=3D"noreferrer noreferrer =
noreferrer noreferrer" =
target=3D"_blank">http://lists.linuxfoundation.org/pipermail/bitcoin-dev/a=
ttachments/20230802/cf726d41/attachment-0001.sig</a>&gt;<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Wed, 2 Aug 2023 18:29:54 +0300<br>
From: Daniel Lipshitz &lt;<a href=3D"mailto:daniel@gap600.com" =
rel=3D"noreferrer noreferrer noreferrer" =
target=3D"_blank">daniel@gap600.com</a>&gt;<br>
To: Peter Todd &lt;<a href=3D"mailto:pete@petertodd.org" rel=3D"noreferrer=
 noreferrer noreferrer" target=3D"_blank">pete@petertodd.org</a>&gt;<br>
Cc: Bitcoin Protocol Discussion<br>
&nbsp; &nbsp; &nbsp; &nbsp; &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer =
noreferrer noreferrer" =
target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;<br>
Subject: Re: [bitcoin-dev] Pull-req to enable Full-RBF by default<br>
Message-ID:<br>
&nbsp; &nbsp; &nbsp; &nbsp; &lt;<a =
href=3D"mailto:CACkWPs_jKUCBPhvj3mGYQu6erLE5qKxXorXAtJpuGCKSaSjVwQ@mail.gm=
ail.com" rel=3D"noreferrer noreferrer noreferrer" =
target=3D"_blank">CACkWPs_jKUCBPhvj3mGYQu6erLE5qKxXorXAtJpuGCKSaSjVwQ@mail=
.gmail.com</a>&gt;<br>
Content-Type: text/plain; charset=3D"utf-8"<br>
<br>
For clarity purposes.<br>
<br>
&nbsp; &nbsp;1. Our research is based on monitoring main net =
transactions and network<br>
&nbsp; &nbsp;activity - as too is our risk engine. We do not engage in =
specific hashing<br>
&nbsp; &nbsp;pool assessments or research.<br>
&nbsp; &nbsp;2. It is not easily possible or comfortable to engage with =
our clients<br>
&nbsp; &nbsp;to offer up their client names and applications - the =
competition is fierce<br>
&nbsp; &nbsp;and like other industries it is not an acceptable approach =
to ask.<br>
&nbsp; &nbsp;3. The information offered by Coinpaid and posted on this =
list, provides<br>
&nbsp; &nbsp;root addresses which using tools like Chainanlysis, or<br>
&nbsp; &nbsp;similar service providers can confirm these addresses are =
associated with<br>
&nbsp; &nbsp;Coinspaid. This can validate a significant amount of our =
traffic.<br>
&nbsp; &nbsp;4. Based on the information provided it will be very =
possible to reach<br>
&nbsp; &nbsp;out to Max at Coinpaid - and will be able to confirm GAP600 =
use with<br>
&nbsp; &nbsp;Coinspaid. This is in addition to me posting an email from =
Max back in Dec<br>
&nbsp; &nbsp;2022 to this list confirming all of this information.<br>
&nbsp; &nbsp;5.&nbsp; It is more than likely that Changelly has not =
implemented our<br>
&nbsp; &nbsp;service across all irts offerings, a large section of their =
business is<br>
&nbsp; &nbsp;servicing partners.<br>
<br>
________________________________<br>
<br>
Daniel Lipshitz<br>
GAP600| <a href=3D"http://www.gap600.com/" rel=3D"noreferrer noreferrer =
noreferrer noreferrer" target=3D"_blank">www.gap600.com</a><br>
Phone: +44 113 4900 117<br>
Skype: daniellipshitz123<br>
Twitter: @daniellipshitz<br>
<br>
<br>
On Wed, Aug 2, 2023 at 1:38?PM Daniel Lipshitz &lt;<a =
href=3D"mailto:daniel@gap600.com" rel=3D"noreferrer noreferrer =
noreferrer" target=3D"_blank">daniel@gap600.com</a>&gt; wrote:<br>
<br>
&gt; Your assessment of my dishonesty is based on your assumption of how =
I<br>
&gt; should be running GAP600, your assumptions are baseless and lack =
commercial<br>
&gt; experience and likewise your conclusions are false.<br>
&gt;<br>
&gt; I have provided already back in December clear access to clarify =
opposite<br>
&gt; our clients corroborated with easily verifiable trxs activity of a =
major<br>
&gt; client of ours. This is more than enough to corroborate our =
statistics.<br>
&gt;<br>
&gt; As far as validating real RBF adoption I have offered a clear =
option here<br>
&gt; <a =
href=3D"https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1661960=
440" rel=3D"noreferrer noreferrer noreferrer noreferrer" =
target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/28132#issuecomme=
nt-1661960440</a><br>
&gt; something like this or similar would offer a clear assessment of =
adoption.<br>
&gt; Since you are not able to provide documents or public emails of =
hashing<br>
&gt; pools confirming there adoption of Full RBF.<br>
&gt; ________________________________<br>
&gt;<br>
&gt; Daniel Lipshitz<br>
&gt; GAP600| <a href=3D"http://www.gap600.com/" rel=3D"noreferrer =
noreferrer noreferrer noreferrer" target=3D"_blank">www.gap600.com</a><br>=

&gt; Phone: +44 113 4900 117<br>
&gt; Skype: daniellipshitz123<br>
&gt; Twitter: @daniellipshitz<br>
&gt;<br>
&gt;<br>
&gt; On Wed, Aug 2, 2023 at 4:28?AM Peter Todd &lt;<a =
href=3D"mailto:pete@petertodd.org" rel=3D"noreferrer noreferrer =
noreferrer" target=3D"_blank">pete@petertodd.org</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; On Wed, Aug 02, 2023 at 01:27:24AM +0300, Daniel Lipshitz =
wrote:<br>
&gt;&gt; &gt; Your research is not thorough and reaches an incorrect =
conclusion.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; As stated many times - we service payment processors and =
some merchants<br>
&gt;&gt; &gt; directly&nbsp; - Coinspaid services multiple merchants and =
process a<br>
&gt;&gt; &gt; significant amount of BTC they are a well known and active =
in the space<br>
&gt;&gt; -<br>
&gt;&gt; &gt; as I provided back in December 2022 a email from Max the =
CEO of<br>
&gt;&gt; Coinspaid<br>
&gt;&gt; &gt; confirming their use of 0-conf as well as providing there =
cluster<br>
&gt;&gt; addresses<br>
&gt;&gt; &gt; to validate there deposit flows see here again -<br>
&gt;&gt; &gt;<br>
&gt;&gt; <a =
href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-Decem=
ber/021239.html" rel=3D"noreferrer noreferrer noreferrer noreferrer" =
target=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/=
2022-December/021239.html</a><br>
&gt;&gt; &gt; - if this is not sufficient then please email <a =
href=3D"mailto:support@coinspaid.com" rel=3D"noreferrer noreferrer =
noreferrer" target=3D"_blank">support@coinspaid.com</a><br>
&gt;&gt; and ask<br>
&gt;&gt; &gt; to be connected to Max or someone from the team who can =
confirm<br>
&gt;&gt; Conspaid is<br>
&gt;&gt; &gt; clients of GAP600. Max also at the time was open to do a =
call, I can<br>
&gt;&gt; check<br>
&gt;&gt; &gt; again now and see if this is still the case and connect =
you.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; That on its own is enough of a sample to validate our =
statistics.<br>
&gt;&gt;<br>
&gt;&gt; Why don't you just give me an example of some merchants using =
Coinspaid,<br>
&gt;&gt; and<br>
&gt;&gt; another example using Coinpayments, who rely on unconfirmed =
transactions?<br>
&gt;&gt; If<br>
&gt;&gt; those merchants actually exist it should be very easy to give =
me some<br>
&gt;&gt; names of<br>
&gt;&gt; them.<br>
&gt;&gt;<br>
&gt;&gt; Without actual concrete examples for everyone to see for =
themselves, why<br>
&gt;&gt; should<br>
&gt;&gt; we believe you?<br>
&gt;&gt;<br>
&gt;&gt; &gt; I have also spoken to Changelly earlier today and they =
offered to email<br>
&gt;&gt; pro<br>
&gt;&gt; &gt; @ <a href=3D"http://changelly.com/" rel=3D"noreferrer =
noreferrer noreferrer noreferrer" target=3D"_blank">changelly.com</a> =
and they will be able to confirm GAP600 as a service<br>
&gt;&gt;<br>
&gt;&gt; Emailed; waiting on a reply.<br>
&gt;&gt;<br>
&gt;&gt; &gt; provider. Also please send me the 1 trx hash you tested =
and I can see<br>
&gt;&gt; if it<br>
&gt;&gt; &gt; was queried to our system and if so offer some info as to =
why it wasnt<br>
&gt;&gt; &gt; approved. Also if you can elaborate how you integrated =
with Changelly -<br>
&gt;&gt; I<br>
&gt;&gt; &gt; can check with them if that area is not integrated with =
GAP600.<br>
&gt;&gt;<br>
&gt;&gt; Why don't you just tell me exactly what service Changelly =
offers that<br>
&gt;&gt; relies on<br>
&gt;&gt; unconfirmed transactions, and what characteristics would meet =
GAP600's<br>
&gt;&gt; risk<br>
&gt;&gt; criteria? I and others on this mailing list could easily do =
test<br>
&gt;&gt; transactions<br>
&gt;&gt; if you told us what we can actually test. If your service =
actually works,<br>
&gt;&gt; then<br>
&gt;&gt; you can safely provide that information.<br>
&gt;&gt;<br>
&gt;&gt; I'm not going to give you any exact tx hashes of transactions =
I've already<br>
&gt;&gt; done, as I don't want to cause any problems for the owners of =
the<br>
&gt;&gt; accounts I<br>
&gt;&gt; borrowed for testing. Given your lack of honesty so far I have =
every<br>
&gt;&gt; reason to<br>
&gt;&gt; believe they might be retalliated against in some way.<br>
&gt;&gt;<br>
&gt;&gt; &gt; As the architect of such a major change to the status of =
0-conf<br>
&gt;&gt; &gt; transactions I would think you would welcome the =
opportunity to speak to<br>
&gt;&gt; &gt; business and users who actual activities will be impacted =
by full RBF<br>
&gt;&gt; &gt; becoming dominant.<br>
&gt;&gt;<br>
&gt;&gt; Funny how you say this, without actually giving any concrete =
examples of<br>
&gt;&gt; businesses that will be affected. Who exactly are these =
businesses?<br>
&gt;&gt; Payment<br>
&gt;&gt; processors obviously don't count.<br>
&gt;&gt;<br>
&gt;&gt; &gt; Are you able to provide the same i.e emails and contacts =
of people at<br>
&gt;&gt; &gt; the mining pools who can confirm they have adopted FULL =
RBF ?<br>
&gt;&gt;<br>
&gt;&gt; I've already had multiple mining pools complain to me that they =
and their<br>
&gt;&gt; employees have been harassed over full-rbf, so obviously I'm =
not going to<br>
&gt;&gt; provide you with any private contact information I have. =
There's no need<br>
&gt;&gt; to<br>
&gt;&gt; expose them to further harassment.<br>
&gt;&gt;<br>
&gt;&gt; If you actually offered an unconfirmed transaction guarantee =
service,<br>
&gt;&gt; with real<br>
&gt;&gt; customers getting an actual benefit, you'd be doing test =
transactions<br>
&gt;&gt; frequently and would already have a very good idea of what =
pools do<br>
&gt;&gt; full-rbf.<br>
&gt;&gt; Why don't you already have this data?<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; <a href=3D"https://petertodd.org/" rel=3D"noreferrer noreferrer =
noreferrer noreferrer" target=3D"_blank">https://petertodd.org</a> =
'peter'[:-1]@<a href=3D"http://petertodd.org/" rel=3D"noreferrer =
noreferrer noreferrer noreferrer" target=3D"_blank">petertodd.org</a><br>
&gt;&gt;<br>
&gt;<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: &lt;<a =
href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments=
/20230802/06762493/attachment-0001.html" rel=3D"noreferrer noreferrer =
noreferrer noreferrer" =
target=3D"_blank">http://lists.linuxfoundation.org/pipermail/bitcoin-dev/a=
ttachments/20230802/06762493/attachment-0001.html</a>&gt;<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Thu, 3 Aug 2023 11:42:40 +0000<br>
From: Peter Todd &lt;<a href=3D"mailto:pete@petertodd.org" =
rel=3D"noreferrer noreferrer noreferrer" =
target=3D"_blank">pete@petertodd.org</a>&gt;<br>
To: <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
rel=3D"noreferrer noreferrer noreferrer" =
target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
Subject: [bitcoin-dev] Pull-req to remove the arbitrary limits on<br>
&nbsp; &nbsp; &nbsp; &nbsp; OP_Return&nbsp; &nbsp; &nbsp; =
&nbsp;outputs<br>
Message-ID: &lt;<a href=3D"mailto:ZMuSsBkWqVXO9qoN@petertodd.org" =
rel=3D"noreferrer noreferrer noreferrer" =
target=3D"_blank">ZMuSsBkWqVXO9qoN@petertodd.org</a>&gt;<br>
Content-Type: text/plain; charset=3D"us-ascii"<br>
<br>
<a href=3D"https://github.com/bitcoin/bitcoin/pull/28130" =
rel=3D"noreferrer noreferrer noreferrer noreferrer" =
target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/28130</a><br>
<br>
Sjors Provoost suggested that I email this mailing list as notice of my =
intent<br>
to get a pull-req merged that would remove the arbitrary 80-byte, 1 =
output /<br>
tx, standardness restrictions on OP_Return outputs. His rationale was =
that<br>
removing these standardness restrictions could potentially open up =
additional<br>
transaction pinning(1) vectors. Since this is a potential problem with =
any<br>
relaxation of standardness rules, I don't consider this to be an =
important<br>
concern. But consider this email your notice.<br>
<br>
At least some miners appear to be mining non-bitcoin-core-standard<br>
transactions. So with respect to the hash power of those miners these =
pinning<br>
vectors may in fact exist already.<br>
<br>
<br>
# References<br>
<br>
1) <a href=3D"https://bitcoinops.org/en/topics/transaction-pinning/" =
rel=3D"noreferrer noreferrer noreferrer noreferrer" =
target=3D"_blank">https://bitcoinops.org/en/topics/transaction-pinning/</a=
><br>
<br>
-- <br>
<a href=3D"https://petertodd.org/" rel=3D"noreferrer noreferrer =
noreferrer noreferrer" target=3D"_blank">https://petertodd.org</a> =
'peter'[:-1]@<a href=3D"http://petertodd.org/" rel=3D"noreferrer =
noreferrer noreferrer noreferrer" target=3D"_blank">petertodd.org</a><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 833 bytes<br>
Desc: not available<br>
URL: &lt;<a =
href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments=
/20230803/33786fbc/attachment.sig" rel=3D"noreferrer noreferrer =
noreferrer noreferrer" =
target=3D"_blank">http://lists.linuxfoundation.org/pipermail/bitcoin-dev/a=
ttachments/20230803/33786fbc/attachment.sig</a>&gt;<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer=
 noreferrer noreferrer" =
target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"=
 rel=3D"noreferrer noreferrer noreferrer noreferrer" =
target=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitco=
in-dev</a><br>
<br>
<br>
------------------------------<br>
<br>
End of bitcoin-dev Digest, Vol 99, Issue 6<br>
******************************************<br>
</blockquote></div></div>
_______________________________________________<br>bitcoin-dev mailing =
list<br>bitcoin-dev@lists.linuxfoundation.org<br>https://lists.linuxfounda=
tion.org/mailman/listinfo/bitcoin-dev<br></div></blockquote></div><br></di=
v></body></html>=

--Apple-Mail=_A96D14F8-1620-4272-BB9D-EABD8E30F61E--