diff options
author | David A. Harding <dave@dtrt.org> | 2020-04-22 16:28:13 -0400 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2020-04-22 20:29:34 +0000 |
commit | cf1b66241237eab46977dd1d453a6e8c6c9d6922 (patch) | |
tree | f89f482dd16896432071a0ba7b10f85fa8274752 | |
parent | 1f66795d4a9dfcb30251ad81c04cebecc5d98cb5 (diff) | |
download | pi-bitcoindev-cf1b66241237eab46977dd1d453a6e8c6c9d6922.tar.gz pi-bitcoindev-cf1b66241237eab46977dd1d453a6e8c6c9d6922.zip |
Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest
-rw-r--r-- | 09/4f765b7f417aee424c7943f92729644192139f | 101 |
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-- + |