summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDavid A. Harding <dave@dtrt.org>2020-04-22 16:28:13 -0400
committerbitcoindev <bitcoindev@gnusha.org>2020-04-22 20:29:34 +0000
commitcf1b66241237eab46977dd1d453a6e8c6c9d6922 (patch)
treef89f482dd16896432071a0ba7b10f85fa8274752
parent1f66795d4a9dfcb30251ad81c04cebecc5d98cb5 (diff)
downloadpi-bitcoindev-cf1b66241237eab46977dd1d453a6e8c6c9d6922.tar.gz
pi-bitcoindev-cf1b66241237eab46977dd1d453a6e8c6c9d6922.zip
Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest
-rw-r--r--09/4f765b7f417aee424c7943f92729644192139f101
1 files changed, 101 insertions, 0 deletions
diff --git a/09/4f765b7f417aee424c7943f92729644192139f b/09/4f765b7f417aee424c7943f92729644192139f
new file mode 100644
index 000000000..c3ae18425
--- /dev/null
+++ b/09/4f765b7f417aee424c7943f92729644192139f
@@ -0,0 +1,101 @@
+Return-Path: <dave@dtrt.org>
+Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
+ by lists.linuxfoundation.org (Postfix) with ESMTP id A015CC0175;
+ Wed, 22 Apr 2020 20:29:34 +0000 (UTC)
+Received: from localhost (localhost [127.0.0.1])
+ by silver.osuosl.org (Postfix) with ESMTP id 8F93220478;
+ Wed, 22 Apr 2020 20:29:34 +0000 (UTC)
+X-Virus-Scanned: amavisd-new at osuosl.org
+Received: from silver.osuosl.org ([127.0.0.1])
+ by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
+ with ESMTP id vPf4B3tw1CuD; Wed, 22 Apr 2020 20:29:33 +0000 (UTC)
+X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
+X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
+Received: from newmail.dtrt.org (li1228-87.members.linode.com [45.79.129.87])
+ by silver.osuosl.org (Postfix) with ESMTPS id 1FDA920134;
+ Wed, 22 Apr 2020 20:29:33 +0000 (UTC)
+Received: from harding by newmail.dtrt.org with local (Exim 4.92)
+ (envelope-from <dave@dtrt.org>)
+ id 1jRLzv-0000X9-O5; Wed, 22 Apr 2020 16:29:31 -0400
+Date: Wed, 22 Apr 2020 16:28:13 -0400
+From: "David A. Harding" <dave@dtrt.org>
+To: Antoine Riard <antoine.riard@gmail.com>
+Message-ID: <20200422202813.oadvvn4j3oe7geq6@ganymede>
+References: <a09f5291-e7c0-0aca-6971-03ace0c38dff@mattcorallo.com>
+ <20200422182454.3y3foxxhiovokovp@ganymede>
+ <CALZpt+HHJ6rKJK8FBdJ1gznWDsfkUo26rOy=mNLbvMwicv9muQ@mail.gmail.com>
+MIME-Version: 1.0
+Content-Type: multipart/signed; micalg=pgp-sha512;
+ protocol="application/pgp-signature"; boundary="jmnpe62yxqvsc2xq"
+Content-Disposition: inline
+In-Reply-To: <CALZpt+HHJ6rKJK8FBdJ1gznWDsfkUo26rOy=mNLbvMwicv9muQ@mail.gmail.com>
+User-Agent: NeoMutt/20180716
+Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
+ lightning-dev <lightning-dev@lists.linuxfoundation.org>
+Subject: Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing
+ Interest
+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: Wed, 22 Apr 2020 20:29:34 -0000
+
+
+--jmnpe62yxqvsc2xq
+Content-Type: text/plain; charset=us-ascii
+Content-Disposition: inline
+Content-Transfer-Encoding: quoted-printable
+
+On Wed, Apr 22, 2020 at 03:03:29PM -0400, Antoine Riard wrote:
+> > In that case, would it be worth re-implementing something like a BIP61
+> reject message but with an extension that returns the txids of any
+> conflicts?
+>=20
+> That's an interesting idea, but an attacker can create a local conflict in
+> your mempool
+
+You don't need a mempool to send a transaction. You can just open
+connections to random Bitcoin nodes directly and try sending your
+transaction. That's what a lite client is going to do anyway. If the
+pinned transaction is in the mempools of a significant number of Bitcoin
+nodes, then it should take just a few random connections to find one of
+those nodes, learn about the conflict, and download the pinned
+transaction.
+
+If that's not acceptable, you could find some other way to poll a
+significant number of people with mempools, e.g. BIP35 mempool messages
+or reusing the payment hash in a bunch of 1 msat probes to LN nodes who
+opt-in to scanning their bitcoind's mempools for a corresponding
+preimage.
+
+-Dave
+
+--jmnpe62yxqvsc2xq
+Content-Type: application/pgp-signature; name="signature.asc"
+
+-----BEGIN PGP SIGNATURE-----
+
+iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAl6gqN0ACgkQ2dtBqWwi
+adNHJQ//cR2TZQGYUugU2m/1YXuKk6Pj9dnmOKGq7K+owyFudp289noe/SJtm4yT
+FEfat7G9ui6BGz3mdct203m+VH+efSu3uCsLLB+DiMTTPH9ofvio2DLcgBuUgPIG
+3z8bSwJlEbUv319V4XlNa8UYFU4ZlNqdP9sbydgACWOLVyv+XxPeK3tlxT4j4IMx
+MHMifZTKMTgTwIO0HqbUaOOhBvULYG+tyE5A31kloUxqksReaZEAp9Oy+f5g0zWz
+bVnqMHJQyi+/j+eu7qtHuexMznSiFXIA7sBDfr8QDWkwTBqYKCK4aVcG/u658yac
+9xSLX8Md2pp9PSyV6Tl6FBo75GsslUyOXTFOCle5PDZYQhMAX3gfWljqyyCGltyz
+xtd6QR/GVvn5G029DMSfxPXuNLgxL8Cp5JMcDrF5TMb8eOnG/NLcCcSKvJWxAR6q
+l5bxQsfrCCagDSTbOXl4CZyYZ/2qUbZxZfniNYEwftWBfksIZamDHGBPQmspL4Hd
+upcKmefLEMGV0fVsKauN0FcyrTOr01ko7DO2zfoLMhfjGAYzdcGeckBWDngaqd8s
+8E8M0eDjXc4up+9j6ZdYEGNhoz2zzTwmzKtm850scTfHsmej2wpDtNv7eCHRZE5A
+jh/k5/rgtF67LiRmWKFcqLl/O2rjOZRUuoKgyjLtshiXweD6bmc=
+=38iq
+-----END PGP SIGNATURE-----
+
+--jmnpe62yxqvsc2xq--
+