From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 705AEC0032 for ; Thu, 3 Aug 2023 12:46:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 38D0641EBE for ; Thu, 3 Aug 2023 12:46:54 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 38D0641EBE Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key, unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm3 header.b=D41NF0Ez X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 5kBJcuP1ny-x for ; Thu, 3 Aug 2023 12:46:51 +0000 (UTC) Received: from wnew2-smtp.messagingengine.com (wnew2-smtp.messagingengine.com [64.147.123.27]) by smtp4.osuosl.org (Postfix) with ESMTPS id D830841BB0 for ; Thu, 3 Aug 2023 12:46:50 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org D830841BB0 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailnew.west.internal (Postfix) with ESMTP id DBBC62B002B4; Thu, 3 Aug 2023 08:46:46 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Thu, 03 Aug 2023 08:46:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1691066806; x=1691074006; bh=N2uHlt18QQnvwA12w1CHrxkRW087 sdy89pVgyN/+i/c=; b=D41NF0Ez5jUR1rt+QtjYgdzjJ+cCcawHfu6cIHxgER8U WIR+6E9OPn/a+Jafstah9UEsBhmer+oK9j4bbL8gNsZF0UqfJIoOyLNBpmRWVSu5 lqP1bkX8G2XziZCup4TriTvnPdVJsdBu4IuCxoW3fcJ0Av/TsPFpK1FzA/SjNNT+ u/p3+ghuwB/J696w16G+uPH6BgOSOeXl8pSUGqJF9bfaqvfnbegp21ltnkHPSBQW JOhj1rc2o2yUI27BwFDCsjkWGJZj6XJZiWizg8DU/YvwMdjI+2Gh4R7UhCZgaflg rIARMarvoXqcMBEaeMGB81thlLrJEnTP0L2KtiEcdg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrkedvgdehgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunddouefvvedqvfhhrhgvrghtshculdeftddtmdenuc fjughrpeffhffvvefukfggtggujgesghdtreertddtvdenucfhrhhomheprfgvthgvrhcu vfhougguuceophgvthgvsehpvghtvghrthhouggurdhorhhgqeenucggtffrrghtthgvrh hnpeffjeevjefhhefhleffieeifeehkeeghfeggeefvddujeehhfdvudekvdduudetteen ucffohhmrghinhepghhithhhuhgsrdgtohhmpdhophgvnhhtihhmvghsthgrmhhpshdroh hrghdpghgrpheitddtrdgtohhmpdhpvghtvghrthhouggurdhorhhgnecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvthgvsehpvghtvghrth houggurdhorhhg X-ME-Proxy: Feedback-ID: i525146e8:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 3 Aug 2023 08:46:45 -0400 (EDT) Received: by localhost (Postfix, from userid 1000) id A48865F823; Thu, 3 Aug 2023 12:46:40 +0000 (UTC) Date: Thu, 3 Aug 2023 12:46:40 +0000 From: Peter Todd To: Daniel Lipshitz Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FGWXgiv238iFSVtN" Content-Disposition: inline In-Reply-To: Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Pull-req to enable Full-RBF by default 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 12:46:54 -0000 --FGWXgiv238iFSVtN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 02, 2023 at 01:38:21PM +0300, Daniel Lipshitz wrote: > Your assessment of my dishonesty is based on your assumption of how I > should be running GAP600, your assumptions are baseless and lack commerci= al > experience and likewise your conclusions are false. >=20 > 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. Claims of "trxs activity" are completely meaningless when you can't demonst= rate that a single client of yours actually relies on unconfirmed transaction acceptance. > 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. Repeating your github comment here for purposes of reply: > A clear and open method to research the adoption of full RBF would look s= omething like this and could easily be done - > > Create 20 trxs (larger numbers better) in between every block and after 3= 0 seconds try replace them. > Run this test for at least a few hours preferably more than 24 hours or e= ven a few days. > See results of how many were replaced. > Ignore trx results if trx are included in blocks before replace trxs are = published. > Have other Bitcoin Core developers independently implement and review the= test results I am baffled at the fact that you claim GAP600 offers a "real-time risk engine"(1) guaranteeing "instant deposits & payments"(1), yet you are not already testing full-rbf adoption yourself in this manner. If your business= was in fact real, it'd be essential to keep track of double spend success rates. > Based on a test like this or something similar it would be reliable to ge= t to an assessment of the adoption of full RBF. As you should know, my OpenTimestamps calendars, https://alice.btc.calendar.opentimestamps.org/ and https://bob.btc.calendar.opentimestamps.org/, have been creating full-rbf double spends multiple times a day since last year. Those calendars have created literally thousands of full-rbf replacements, providing ample test data. If your business was real - if you actually have a "real time risk engine" = that monitors mempools - you'd already know this. You'd also know about the successful full-rbf replacements that Alice got mined today: 291e1abf146209839f8910cf9ede6979bb12e6efa6d73f52ca7ae0476eafa6a5 - AntPool e7ea70c2e366ef035ed0428c704c55e5331211200c6e0298eb85a574812aa010 - Binance = Pool aa9e034283cc50a3cb042284833607bc49dea275854004a3757acf776e679a6b - Poolin ae74600b66ccf9d8ee8d62e5881581b5baff11117e47ea51c3e4d1fee1612504 - AntPool Those four transactions are each part of a chain of replacements, and every chain started with a transaction paying well above the minimum relay fee in present mempool conditions. Tell me, how do you think those full-rbf replacements get mined? On Wed, Aug 02, 2023 at 06:29:54PM +0300, Daniel Lipshitz wrote: > For clarity purposes. >=20 > 1. Our research is based on monitoring main net transactions and netwo= rk > activity - as too is our risk engine. We do not engage in specific has= hing > pool assessments or research. So if you are "monitoring main net transactions and network activity", why = are you not already aware of the many full-rbf replacements getting mined every day? > 2. It is not easily possible or comfortable to engage with our clients > to offer up their client names and applications - the competition is f= ierce > and like other industries it is not an acceptable approach to ask. > 3. The information offered by Coinpaid and posted on this list, provid= es > root addresses which using tools like Chainanlysis, or > similar service providers can confirm these addresses are associated w= ith > Coinspaid. This can validate a significant amount of our traffic. This reminds me of how Craig Wright appears to have picked a bunch of bitco= in addresses off of a "rich list" and fraudulently claimed those addresses to = be his. Anyone can create a list of addresses from blockchain data. That is not pro= of that any actual merchant relies on unconfirmed transactions. To prove that = you need to provide the names of those merchant(s), so others can actually veri= fy that they provides things of value in exchange for an unconfirmed transacti= on. > 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. Again, Coinspaid is a merchant processor. Unless you or they actually provi= de details on real merchants making use of your claimed service, you have not proven anything of value. > 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. FYI I emailed pro@changelly.com two days ago, asking for confirmation that = they use GAP600, and information on how exactly they rely on unconfirmed transactions. So far I have not gotten a reply. # References 1) https://www.gap600.com/ --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --FGWXgiv238iFSVtN Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmTLoa4ACgkQLly11TVR Lze9OBAArYGoOKz/bLEGvgTKf0wBv5Fc8LbVlTA0uNA4++tD2G3ID/YtQvt0g4da 1SWehWlWg7cUNKOcN/lhsWdeoptoVxCwyaYiTm3ehpfuP8XzoyriCfrkMO/hrJ4q nqHO6xPcIHqQmyhiS1vfzPATQZ/dlAmdmNdmsK4KF65LHQiDkJ0lsMuT31ny0a8N 9hy9ktK8FhzsCnvSpwvW8fabqdZBhLqmykUeRRSHChtaBnLJgBhN9WKMYRUbwdc3 0TPqWyljgjKLLA+5d46a+83tI/25rc0mIsEtHWjauzaDEvQI9/BGIIzb4krZFh1x fxPTBrf6d+HGkzuTBZfcvXwbdbaMzdtaQ/KlgYdwDV76d8enubcFYIS3MOro6kkM ES8v+Q5sSAzkBMuRKk4lt+1N8Nj1kfruTm1UFs0aLV/zf+u1ekdRTZIppqRnFlJ1 8D7ybn64V+4lkfqt3AQ1LAY8Nx6QwjsYIneJMdi/q9+Wcnnd6ZmVG93py04hPd+Q iUDp2YUvZ+pMP5TZ7qewzLT0T5ZgSRxjgNcSwG5nq397Y2Dgf6MsflWlB19pS9Im 2jZpvNgmzbuxUF7CIcv3m2vZBfOz3fIC/OS6C9/7JrdPahEHNGd9UBKYuDpBRWua SF1muBl698O5JwUKf54Yce2DVXIvDkfv+yM+gXkMytAuxlezs5Y= =/Ab7 -----END PGP SIGNATURE----- --FGWXgiv238iFSVtN--