Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8009AC0032 for ; 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 ; 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 ; 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 ; 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: To: GamedevAlice , Bitcoin Protocol Discussion In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 = 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 , = > wrote: >> Send bitcoin-dev mailing list submissions to >> 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 = >>=20 >> You can reach the person managing the list at >> 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 > >> To: bitcoin-dev@lists.linuxfoundation.org = , Keagan McClelland >> > >> Subject: Re: [bitcoin-dev] Concern about "Inscriptions". (Keagan >> McClelland) >> Message-ID: >> = > >>=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 = - 0xBF60A699.asc >> Type: application/pgp-keys >> Size: 657 bytes >> Desc: not available >> URL: = >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: signature.asc >> Type: application/pgp-signature >> Size: 249 bytes >> Desc: OpenPGP digital signature >> URL: = >>=20 >> ------------------------------ >>=20 >> Message: 2 >> Date: Wed, 2 Aug 2023 18:29:54 +0300 >> From: Daniel Lipshitz > >> To: Peter Todd > >> Cc: Bitcoin Protocol Discussion >> > >> Subject: Re: [bitcoin-dev] Pull-req to enable Full-RBF by default >> Message-ID: >> = > >> 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 >> Phone: +44 113 4900 117 >> Skype: daniellipshitz123 >> Twitter: @daniellipshitz >>=20 >>=20 >> On Wed, Aug 2, 2023 at 1:38?PM Daniel Lipshitz > 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 >> > Phone: +44 113 4900 117 >> > Skype: daniellipshitz123 >> > Twitter: @daniellipshitz >> > >> > >> > On Wed, Aug 2, 2023 at 4:28?AM Peter Todd > 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 >> >> 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 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 = 'peter'[:-1]@petertodd.org >> >> >> > >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: = >>=20 >> ------------------------------ >>=20 >> Message: 3 >> Date: Thu, 3 Aug 2023 11:42:40 +0000 >> From: Peter Todd > >> To: bitcoin-dev@lists.linuxfoundation.org = >> Subject: [bitcoin-dev] Pull-req to remove the arbitrary limits on >> OP_Return outputs >> Message-ID: > >> 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 = 'peter'[:-1]@petertodd.org >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: signature.asc >> Type: application/pgp-signature >> Size: 833 bytes >> Desc: not available >> URL: = >>=20 >> ------------------------------ >>=20 >> Subject: Digest Footer >>=20 >> _______________________________________________ >> bitcoin-dev mailing list >> 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
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 :

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. 

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. 



On Thu, Aug 3, 2023, 7:43 AM , <bitcoin-dev-request@lists.linuxfoundation.org> = wrote:
Send bitcoin-dev = mailing list submissions to
        bitcoin-dev@lists.linuxfoundation.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.linuxfoundation.org/mailman/listinfo/bitco= in-dev
or, via email, send a message with subject or body 'help' to
        bitcoin-dev-request@lists.linuxfoundation.org

You can reach the person managing the list at
        bitcoin-dev-owner@lists.linuxfoundation.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of bitcoin-dev digest..."


Today's Topics:

   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)


= ----------------------------------------------------------------------
=
Message: 1
Date: Wed, 02 Aug 2023 13:50:30 +0000
From: Einherjar <realeinherjar@proton.me>
To: bitcoin-dev@lists.linuxfoundation.org, Keagan = McClelland
        <keagan.mcclelland@gmail.com>
Subject: Re: [bitcoin-dev] Concern about "Inscriptions". (Keagan
        McClelland)
Message-ID:
        = <EGcuw9I68gwGmFMMw_OstpvAHQ0sWleUi3Jfa8t9A14fa5PGYR2EAxJIjwKd8jo5JtUfmy= w9taF1qEsQlVoXBpLUxixdlBpIOEhuXzTUSEc=3D@proton.me>

Content-Type: text/plain; charset=3D"utf-8"

About price space in the UTXO set:

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.

> 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.
>

> Cheers,
> Keags


Einherjar - E7ED 7E35 F072 CA83

Sent with Proton Mail secure email.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - realeinherjar@proton.me - 0xBF60A699.asc
Type: application/pgp-keys
Size: 657 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/a= ttachments/20230802/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/a= ttachments/20230802/cf726d41/attachment-0001.sig>

------------------------------

Message: 2
Date: Wed, 2 Aug 2023 18:29:54 +0300
From: Daniel Lipshitz <daniel@gap600.com>
To: Peter Todd <pete@petertodd.org>
Cc: Bitcoin Protocol Discussion
        <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Pull-req to enable Full-RBF by default
Message-ID:
        <CACkWPs_jKUCBPhvj3mGYQu6erLE5qKxXorXAtJpuGCKSaSjVwQ@mail= .gmail.com>
Content-Type: text/plain; charset=3D"utf-8"

For clarity purposes.

   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.

________________________________

Daniel Lipshitz
GAP600| www.gap600.com
Phone: +44 113 4900 117
Skype: daniellipshitz123
Twitter: @daniellipshitz


On Wed, Aug 2, 2023 at 1:38?PM Daniel Lipshitz <daniel@gap600.com> wrote:

> 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#issuecomme= nt-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
= > Phone: +44 113 4900 117
> Skype: daniellipshitz123
> Twitter: @daniellipshitz
>
>
> On Wed, Aug 2, 2023 at 4:28?AM Peter Todd <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/021239.html
>> > - if this is not sufficient then please email 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 = 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 = 'peter'[:-1]@petertodd.org
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/a= ttachments/20230802/06762493/attachment-0001.html>

------------------------------

Message: 3
Date: Thu, 3 Aug 2023 11:42:40 +0000
From: Peter Todd <pete@petertodd.org>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] Pull-req to remove the arbitrary limits on
        OP_Return      =  outputs
Message-ID: <ZMuSsBkWqVXO9qoN@petertodd.org>
Content-Type: text/plain; charset=3D"us-ascii"

https://github.com/bitcoin/bitcoin/pull/28130

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.

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.


# References

1) https://bitcoinops.org/en/topics/transaction-pinning/

--
https://petertodd.org = 'peter'[:-1]@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/a= ttachments/20230803/33786fbc/attachment.sig>

------------------------------

Subject: Digest Footer

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitco= in-dev


------------------------------

End of bitcoin-dev Digest, Vol 99, Issue 6
******************************************
_______________________________________________
bitcoin-dev mailing = list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfounda= tion.org/mailman/listinfo/bitcoin-dev

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