summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAnthony Towns <aj@erisian.com.au>2022-05-25 14:55:35 -0400
committerbitcoindev <bitcoindev@gnusha.org>2022-05-25 18:55:46 +0000
commitbb2cc33733ef58392836812ce6482381fa88428b (patch)
tree58f3ba44b0004f6360a4dcd799658069e61bbc3a
parent84b69d49091f45c8ad89df59a111f0da78c1dd25 (diff)
downloadpi-bitcoindev-bb2cc33733ef58392836812ce6482381fa88428b.tar.gz
pi-bitcoindev-bb2cc33733ef58392836812ce6482381fa88428b.zip
Re: [bitcoin-dev] Package Relay Proposal
-rw-r--r--10/bf07536f1a6ace28774adbb65e88cfbb307543140
1 files changed, 140 insertions, 0 deletions
diff --git a/10/bf07536f1a6ace28774adbb65e88cfbb307543 b/10/bf07536f1a6ace28774adbb65e88cfbb307543
new file mode 100644
index 000000000..0a61733ac
--- /dev/null
+++ b/10/bf07536f1a6ace28774adbb65e88cfbb307543
@@ -0,0 +1,140 @@
+Return-Path: <aj@erisian.com.au>
+Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
+ by lists.linuxfoundation.org (Postfix) with ESMTP id 5DAB3C002D
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 25 May 2022 18:55:46 +0000 (UTC)
+Received: from localhost (localhost [127.0.0.1])
+ by smtp3.osuosl.org (Postfix) with ESMTP id 374006136B
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 25 May 2022 18:55:46 +0000 (UTC)
+X-Virus-Scanned: amavisd-new at osuosl.org
+X-Spam-Flag: NO
+X-Spam-Score: -1.902
+X-Spam-Level:
+X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5
+ tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
+ autolearn=ham autolearn_force=no
+Received: from smtp3.osuosl.org ([127.0.0.1])
+ by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
+ with ESMTP id Ls40MwATBaNr
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 25 May 2022 18:55:45 +0000 (UTC)
+X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
+Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193])
+ by smtp3.osuosl.org (Postfix) with ESMTPS id 66FC66136A
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 25 May 2022 18:55:45 +0000 (UTC)
+Received: from aj@azure.erisian.com.au (helo=[127.0.0.1])
+ by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian))
+ id 1ntwAX-00057v-CN; Thu, 26 May 2022 04:55:42 +1000
+Date: Wed, 25 May 2022 14:55:35 -0400
+From: Anthony Towns <aj@erisian.com.au>
+To: Gloria Zhao <gloriajzhao@gmail.com>,
+ Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
+User-Agent: K-9 Mail for Android
+In-Reply-To: <CAFXO6=K6FXNFwOZ3VyT6_RZY2F2BX+iTy+MyOshRBfNnn9Hqyg@mail.gmail.com>
+References: <CAFXO6=JROe_9ih2h+_CCH-UbxehsM5RQ6YyNnPesEpveBEtdow@mail.gmail.com>
+ <20220518003531.GA4402@erisian.com.au>
+ <CAFXO6=LWM4eHM=zJhejw5981+8h7QHTbwpz0jEbWkrLOX0037Q@mail.gmail.com>
+ <20220523213416.GA6151@erisian.com.au>
+ <CAFXO6=KXToP2MFWQ1JVKX6jV++utw8E4Z13T4cH+mfgtyeUx_A@mail.gmail.com>
+ <2B3D1901-901C-4000-A2B9-F6857FCE2847@erisian.com.au>
+ <CAFXO6=K6FXNFwOZ3VyT6_RZY2F2BX+iTy+MyOshRBfNnn9Hqyg@mail.gmail.com>
+Message-ID: <8FFE048D-854F-4D34-85DA-CE523C16EEB0@erisian.com.au>
+MIME-Version: 1.0
+Content-Type: text/plain;
+ charset=utf-8
+Content-Transfer-Encoding: quoted-printable
+X-Spam-Score-int: -28
+X-Spam-Bar: --
+Subject: Re: [bitcoin-dev] Package Relay Proposal
+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, 25 May 2022 18:55:46 -0000
+
+On 24 May 2022 5:05:35 pm GMT-04:00, Gloria Zhao via bitcoin-dev <bitcoin-d=
+ev@lists=2Elinuxfoundation=2Eorg> wrote:
+>To clarify, in this situation, I'm imagining something like
+>A: 0 sat, 100vB
+>B: 1500 sat, 100vB
+>C: 0 sat, 100vB
+>X: 500 sat, 100vB
+>feerate floor is 3sat/vB
+>
+>With the algo:
+>> * is X alone above my fee rate? no, then forget it
+>> * otherwise, s :=3D X=2Esize, f :=3D X=2Efees, R :=3D [X]
+>> * for P =3D P1=2E=2EPn:
+>> * do I already have P? then skip to the next parent
+>> * s +=3D P=2Esize, f +=3D P=2Efees, R +=3D [P]
+>> * if f/s above my fee rate floor? if so, request all the txs in R
+>
+>We'd erroneously ask for A+B+C+X, but really we should only take A+B=2E
+>But wouldn't A+B also be a package that was announced for B?
+
+In theory, yes, but maybe it was announced earlier (while our node was dow=
+n?) or had dropped from our mempool or similar, either way we don't have th=
+ose txs yet=2E
+
+>Please lmk if you were imagining something different=2E I think I may be
+>missing something=2E
+
+That's what I was thinking, yes=2E
+
+So the other thing is what happens if the peer announcing packages to us i=
+s dishonest?
+
+They announce pkg X, say X has parents A B C and the fee rate is garbage=
+=2E But actually X has parent D and the fee rate is excellent=2E Do we requ=
+est the package from another peer, or every peer, to double check? Otherwis=
+e we're allowing the first peer we ask about a package to censor that tx fr=
+om us?
+
+I think the fix for that is just to provide the fee and weight when announ=
+cing the package rather than only being asked for its info? Then if one pee=
+r makes it sound like a good deal you ask for the parent txids from them, d=
+edupe, request, and verify they were honest about the parents=2E
+
+>> Is it plausible to add the graph in?
+
+Likewise, I think you'd have to have the graph info from many nodes if you=
+'re going to make decisions based on it and don't want hostile peers to be =
+able to trick you into ignoring txs=2E
+
+Other idea: what if you encode the parent txs as a short hash of the wtxid=
+ (something like bip152 short ids? perhaps seeded per peer so collisions wi=
+ll be different per peer?) and include that in the inv announcement? Would =
+that work to avoid a round trip almost all of the time, while still giving =
+you enough info to save bw by deduping parents?
+
+
+> For a maximum 25 transactions,
+>23*24/2 =3D 276, seems like 36 bytes for a child-with-parents package=2E
+
+If you're doing short ids that's maybe 25*4B=3D100B already, then the abov=
+e is up to 36% overhead, I guess=2E Might be worth thinking more about, but=
+ maybe more interesting with ancestors than just parents=2E
+
+>Also side note, since there are no size/count params, wondering if we
+>should just have "version" in "sendpackages" be a bit field instead of
+>sending a message for each version=2E 32 versions should be enough right?
+
+Maybe but a couple of messages per connection doesn't really seem worth ar=
+guing about?
+
+Cheers,
+aj
+
+
+--=20
+Sent from my phone=2E
+