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 = <bitcoin-dev@lists.linuxfoundation.org> 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. </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. </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 , <<a = href=3D"mailto:bitcoin-dev-request@lists.linuxfoundation.org" = rel=3D"noreferrer noreferrer" = target=3D"_blank">bitcoin-dev-request@lists.linuxfoundation.org</a>> = 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> <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> <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> <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> <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> 1. Re: Concern about "Inscriptions". (Keagan McClelland) = (Einherjar)<br> 2. Re: Pull-req to enable Full-RBF by default (Daniel = Lipshitz)<br> 3. Pull-req to remove the arbitrary limits on = OP_Return outputs<br> (Peter Todd)<br> <br> <br> = ----------------------------------------------------------------------<br>= <br> Message: 1<br> Date: Wed, 02 Aug 2023 13:50:30 +0000<br> From: Einherjar <<a href=3D"mailto:realeinherjar@proton.me" = rel=3D"noreferrer noreferrer noreferrer" = target=3D"_blank">realeinherjar@proton.me</a>><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> <<a = href=3D"mailto:keagan.mcclelland@gmail.com" rel=3D"noreferrer noreferrer = noreferrer" target=3D"_blank">keagan.mcclelland@gmail.com</a>><br> Subject: Re: [bitcoin-dev] Concern about "Inscriptions". (Keagan<br> McClelland)<br> Message-ID:<br> = <EGcuw9I68gwGmFMMw_OstpvAHQ0sWleUi3Jfa8t9A14fa5PGYR2EAxJIjwKd8jo5JtUfmy= w9taF1qEsQlVoXBpLUxixdlBpIOEhuXzTUSEc=3D@<a href=3D"http://proton.me/" = rel=3D"noreferrer noreferrer noreferrer noreferrer" = target=3D"_blank">proton.me</a>><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> > There is an open question as to whether or not we should figure out = a way<br> > to price space in the UTXO set. I think it is fair to say that = given the<br> > fact that the UTXO set space remains unpriced that we actually have = no way<br> > to determine whether some of these transactions are spam or not. = The UTXO<br> > set must be maintained by all nodes including pruned nodes, whereas = main<br> > block and witness data do not have the same type of indefinite = footprint,<br> > so in some sense it is an even more significant resource than chain = space.<br> > We may very well discover that if we price UTXOs in a way that = reflect the<br> > resource costs that usage of inscriptions would vanish. The trouble = though<br> > is that such a mechanism would imply having to pay "rent" for an = "account"<br> > with Bitcoin, a proposition that would likely be offensive to a = significant<br> > portion of the Bitcoin user base.<br> > <br> <br> > Cheers,<br> > 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: <<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>><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: <<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>><br> <br> ------------------------------<br> <br> Message: 2<br> Date: Wed, 2 Aug 2023 18:29:54 +0300<br> From: Daniel Lipshitz <<a href=3D"mailto:daniel@gap600.com" = rel=3D"noreferrer noreferrer noreferrer" = target=3D"_blank">daniel@gap600.com</a>><br> To: Peter Todd <<a href=3D"mailto:pete@petertodd.org" rel=3D"noreferrer= noreferrer noreferrer" target=3D"_blank">pete@petertodd.org</a>><br> Cc: Bitcoin Protocol Discussion<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> Subject: Re: [bitcoin-dev] Pull-req to enable Full-RBF by default<br> Message-ID:<br> <<a = href=3D"mailto:CACkWPs_jKUCBPhvj3mGYQu6erLE5qKxXorXAtJpuGCKSaSjVwQ@mail.gm= ail.com" rel=3D"noreferrer noreferrer noreferrer" = target=3D"_blank">CACkWPs_jKUCBPhvj3mGYQu6erLE5qKxXorXAtJpuGCKSaSjVwQ@mail= .gmail.com</a>><br> Content-Type: text/plain; charset=3D"utf-8"<br> <br> For clarity purposes.<br> <br> 1. Our research is based on monitoring main net = transactions and network<br> activity - as too is our risk engine. We do not engage in = specific hashing<br> pool assessments or research.<br> 2. It is not easily possible or comfortable to engage with = our clients<br> to offer up their client names and applications - the = competition is fierce<br> and like other industries it is not an acceptable approach = to ask.<br> 3. The information offered by Coinpaid and posted on this = list, provides<br> root addresses which using tools like Chainanlysis, or<br> similar service providers can confirm these addresses are = associated with<br> Coinspaid. This can validate a significant amount of our = traffic.<br> 4. Based on the information provided it will be very = possible to reach<br> out to Max at Coinpaid - and will be able to confirm GAP600 = use with<br> Coinspaid. This is in addition to me posting an email from = Max back in Dec<br> 2022 to this list confirming all of this information.<br> 5. It is more than likely that Changelly has not = implemented our<br> service across all irts offerings, a large section of their = business is<br> 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 <<a = href=3D"mailto:daniel@gap600.com" rel=3D"noreferrer noreferrer = noreferrer" target=3D"_blank">daniel@gap600.com</a>> wrote:<br> <br> > Your assessment of my dishonesty is based on your assumption of how = I<br> > should be running GAP600, your assumptions are baseless and lack = commercial<br> > experience and likewise your conclusions are false.<br> ><br> > I have provided already back in December clear access to clarify = opposite<br> > our clients corroborated with easily verifiable trxs activity of a = major<br> > client of ours. This is more than enough to corroborate our = statistics.<br> ><br> > As far as validating real RBF adoption I have offered a clear = option here<br> > <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> > something like this or similar would offer a clear assessment of = adoption.<br> > Since you are not able to provide documents or public emails of = hashing<br> > pools confirming there adoption of Full RBF.<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 4:28?AM Peter Todd <<a = href=3D"mailto:pete@petertodd.org" rel=3D"noreferrer noreferrer = noreferrer" target=3D"_blank">pete@petertodd.org</a>> wrote:<br> ><br> >> On Wed, Aug 02, 2023 at 01:27:24AM +0300, Daniel Lipshitz = wrote:<br> >> > Your research is not thorough and reaches an incorrect = conclusion.<br> >> ><br> >> > As stated many times - we service payment processors and = some merchants<br> >> > directly - Coinspaid services multiple merchants and = process a<br> >> > significant amount of BTC they are a well known and active = in the space<br> >> -<br> >> > as I provided back in December 2022 a email from Max the = CEO of<br> >> Coinspaid<br> >> > confirming their use of 0-conf as well as providing there = cluster<br> >> addresses<br> >> > to validate there deposit flows see here again -<br> >> ><br> >> <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> >> > - 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> >> and ask<br> >> > to be connected to Max or someone from the team who can = confirm<br> >> Conspaid is<br> >> > clients of GAP600. Max also at the time was open to do a = call, I can<br> >> check<br> >> > again now and see if this is still the case and connect = you.<br> >> ><br> >> > That on its own is enough of a sample to validate our = statistics.<br> >><br> >> Why don't you just give me an example of some merchants using = Coinspaid,<br> >> and<br> >> another example using Coinpayments, who rely on unconfirmed = transactions?<br> >> If<br> >> those merchants actually exist it should be very easy to give = me some<br> >> names of<br> >> them.<br> >><br> >> Without actual concrete examples for everyone to see for = themselves, why<br> >> should<br> >> we believe you?<br> >><br> >> > I have also spoken to Changelly earlier today and they = offered to email<br> >> pro<br> >> > @ <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> >><br> >> Emailed; waiting on a reply.<br> >><br> >> > provider. Also please send me the 1 trx hash you tested = and I can see<br> >> if it<br> >> > was queried to our system and if so offer some info as to = why it wasnt<br> >> > approved. Also if you can elaborate how you integrated = with Changelly -<br> >> I<br> >> > can check with them if that area is not integrated with = GAP600.<br> >><br> >> Why don't you just tell me exactly what service Changelly = offers that<br> >> relies on<br> >> unconfirmed transactions, and what characteristics would meet = GAP600's<br> >> risk<br> >> criteria? I and others on this mailing list could easily do = test<br> >> transactions<br> >> if you told us what we can actually test. If your service = actually works,<br> >> then<br> >> you can safely provide that information.<br> >><br> >> I'm not going to give you any exact tx hashes of transactions = I've already<br> >> done, as I don't want to cause any problems for the owners of = the<br> >> accounts I<br> >> borrowed for testing. Given your lack of honesty so far I have = every<br> >> reason to<br> >> believe they might be retalliated against in some way.<br> >><br> >> > As the architect of such a major change to the status of = 0-conf<br> >> > transactions I would think you would welcome the = opportunity to speak to<br> >> > business and users who actual activities will be impacted = by full RBF<br> >> > becoming dominant.<br> >><br> >> Funny how you say this, without actually giving any concrete = examples of<br> >> businesses that will be affected. Who exactly are these = businesses?<br> >> Payment<br> >> processors obviously don't count.<br> >><br> >> > Are you able to provide the same i.e emails and contacts = of people at<br> >> > the mining pools who can confirm they have adopted FULL = RBF ?<br> >><br> >> I've already had multiple mining pools complain to me that they = and their<br> >> employees have been harassed over full-rbf, so obviously I'm = not going to<br> >> provide you with any private contact information I have. = There's no need<br> >> to<br> >> expose them to further harassment.<br> >><br> >> If you actually offered an unconfirmed transaction guarantee = service,<br> >> with real<br> >> customers getting an actual benefit, you'd be doing test = transactions<br> >> frequently and would already have a very good idea of what = pools do<br> >> full-rbf.<br> >> Why don't you already have this data?<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> >><br> ><br> -------------- next part --------------<br> An HTML attachment was scrubbed...<br> URL: <<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>><br> <br> ------------------------------<br> <br> Message: 3<br> Date: Thu, 3 Aug 2023 11:42:40 +0000<br> From: Peter Todd <<a href=3D"mailto:pete@petertodd.org" = rel=3D"noreferrer noreferrer noreferrer" = target=3D"_blank">pete@petertodd.org</a>><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> OP_Return = outputs<br> Message-ID: <<a href=3D"mailto:ZMuSsBkWqVXO9qoN@petertodd.org" = rel=3D"noreferrer noreferrer noreferrer" = target=3D"_blank">ZMuSsBkWqVXO9qoN@petertodd.org</a>><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: <<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>><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--