path: root/3d/a6e18c4c38d76c70fbd9628fd6aa4c8ae73a07

Return-Path: <sdaftuar@gmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id CEE85C0177
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 Feb 2020 19:48:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id C2BEF86EB1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 Feb 2020 19:48:36 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 4jsQHsMhGrua
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 Feb 2020 19:48:36 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-il1-f181.google.com (mail-il1-f181.google.com
 [209.85.166.181])
 by hemlock.osuosl.org (Postfix) with ESMTPS id E45A886E6E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 Feb 2020 19:48:35 +0000 (UTC)
Received: by mail-il1-f181.google.com with SMTP id i7so240537ilr.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 Feb 2020 11:48:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:from:date:message-id:subject:to;
 bh=QopFMB6HriDCIsYxEe5EBLVoV+Mj0mXUT5bSYKWZC2o=;
 b=d4ah1qlEICqn42ataxs/y1qz9px086IzJ+rdLmuZ8Aw090CN4sUpqmAGenYhNpq6C7
 4BKejlcnAF4EnMQwI7LoTZM+LuEqyj66EBvA+92RA5zNe3uZl5BMVpO4CfeuQJXAWJ4S
 zV+cHwirk3zh93z4sHF8rry1yqjsW8IHRwlQaFwt3mpBNPu0w+DKki1QEWMX3QQl7VKg
 7n8vMged0vLOSCAHZ/tQ6gV4ByWcmMZvtbcMz1Bn/TUy3AnPP+945WQZTCMVic7YdR96
 9z10lLDQIOkuOiZ4+1zvV5ATqwgLsVpwSIB5fyF5KYK8st6SMAN2FT8UdQSRQavIn1oy
 HkmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=QopFMB6HriDCIsYxEe5EBLVoV+Mj0mXUT5bSYKWZC2o=;
 b=QgnTvsFBaXTrK0rtIpZIvA0wMfE66WU3OP50MS0Ipi7les/GlCRrei24zY3IBC2XPd
 NCHFixQAGGXoV/d2MoQ/K1Y3Zd0Gfz6T/sy6W8qUdHmM27XZPHjS/ayKomx7sTfSRGxg
 8xqIueyRlTo2v93PusH+OJ+GZx7tMQ7mB9b8Rkt5Ym0Y2PxpWms9X3SZRHqsMAZH1QPN
 Q9S6Wk2nxpWHMIVPTUgipWqCb/ksgxPiAMEY43ASKjWUVQjkELYlJ14lo+52qqUq7I8j
 8TQV9Bh5H2qLnxDOY4mKuu+zZ7mhDJlfUvTtnavbLs/nkz3tP8aVVI78TPRVEM7DIGXH
 VZoA==
X-Gm-Message-State: APjAAAUXF5MFo0i4E6nmOMNTmCT0NKTCpfQINOFSoicNVYCupk3fSHzc
 F8j+tE8kDx8pMlBp4xuSPQ4UUtNelTiQC0mC1akpPOx0
X-Google-Smtp-Source: APXvYqxFl8kRGZXVaGCKBwL++pgmYG3SW2HcMpwJNu+sB8ZxwJ1Y9J2tGjSq5PRB75MV/wu94JlapAUCTgT2QdF4d8A=
X-Received: by 2002:a92:1d92:: with SMTP id g18mr279367ile.23.1582660114458;
 Tue, 25 Feb 2020 11:48:34 -0800 (PST)
MIME-Version: 1.0
From: Suhas Daftuar <sdaftuar@gmail.com>
Date: Tue, 25 Feb 2020 14:48:23 -0500
Message-ID: <CAFp6fsFzRT=iYM=YK6hbhD3WB0Scoo8hDT-tOcjuyOFsBc00gw@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000ec2aa6059f6bc548"
Subject: [bitcoin-dev] A proposal for WTXID-based transaction relay
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: Tue, 25 Feb 2020 19:48:37 -0000

--000000000000ec2aa6059f6bc548
Content-Type: text/plain; charset="UTF-8"

Hi all,

I've been working on a proposal to add support for relaying transactions
based on their wtxid, rather than just their txid.  The current draft is at
https://github.com/sdaftuar/bips/blob/2020-02-wtxid-relay/bip-wtxid-relay.mediawiki,
and for some background I'll paste the motivation section here:

Historically, the INV messages sent on the Bitcoin peer-to-peer network to
> announce transactions refer to transactions by their txid, which is a hash
> of the transaction that does not include the witness (see BIP 141). This
> has been the case even since Segregated Witness (BIP 141/143/144) has been
> adopted by the network.
>


> Not committing to the witness in transaction announcements creates
> inefficiencies: because a transaction's witness can be malleated without
> altering the txid, a node in receipt of a witness transaction that the node
> does not accept will generally still download that same transaction when
> announced by other peers. This is because the alternative -- of not
> downloading a given txid after rejecting a transaction with that txid --
> would allow a third party to interfere with transaction relay by malleating
> a transaction's witness and announcing the resulting invalid transaction to
> nodes, preventing relay of the valid version of the transaction as well.
>


> We can eliminate this concern by using the wtxid in place of the txid when
> announcing and fetching transactions.
>

One point specifically that I'm seeking feedback on is feature negotiation:
for efficiency, I think it makes sense for peers to negotiate at the
beginning of a connection whether they are going to use wtxid- or
txid-based, prior to announcing any transactions.  To achieve this, I
propose in the BIP to send a message between receiving a VERSION message
and prior to sending VERACK (to nodes advertising version at least 70016)
to announce support for this new feature; if both sides send it then they
each know to enable it on the link.  My thinking is that in general, it'd
be great to use messages sent between VERSION and VERACK to negotiate
features prior to fully initializing a peer connection (it's sort of a
natural way to extend what we might want to send in a VERSION message,
without breaking existing VERSION-message parsers).  However, I don't know
whether inserting a message before VERACK would break any assumptions of
other software on the network, or if this is a problematic paradigm for
some reason, so I'd welcome feedback here.

Thanks,
Suhas

--000000000000ec2aa6059f6bc548
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi all,<div><br></div><div>I&#39;ve been working on a prop=
osal to add support for relaying transactions based on their wtxid, rather =
than just their txid.=C2=A0 The current draft is at=C2=A0<a href=3D"https:/=
/github.com/sdaftuar/bips/blob/2020-02-wtxid-relay/bip-wtxid-relay.mediawik=
i" target=3D"_blank">https://github.com/sdaftuar/bips/blob/2020-02-wtxid-re=
lay/bip-wtxid-relay.mediawiki</a>, and for some background I&#39;ll paste t=
he motivation section here:</div><div><br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex">Historically, the INV messages sent on the Bitcoin p=
eer-to-peer network to announce transactions refer to transactions by their=
 txid, which is a hash of the transaction that does not include the witness=
 (see BIP 141). This has been the case even since Segregated Witness (BIP 1=
41/143/144) has been adopted by the network.<br></blockquote><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">Not committing to the =
witness in transaction announcements creates inefficiencies: because a tran=
saction&#39;s witness can be malleated without altering the txid, a node in=
 receipt of a witness transaction that the node does not accept will genera=
lly still download that same transaction when announced by other peers. Thi=
s is because the alternative -- of not downloading a given txid after rejec=
ting a transaction with that txid -- would allow a third party to interfere=
 with transaction relay by malleating a transaction&#39;s witness and annou=
ncing the resulting invalid transaction to nodes, preventing relay of the v=
alid version of the transaction as well.<br></blockquote><div>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">We can eliminate this conc=
ern by using the wtxid in place of the txid when announcing and fetching tr=
ansactions.<br></blockquote><div><br></div><div>One point specifically that=
 I&#39;m seeking feedback on is feature negotiation: for efficiency, I thin=
k it makes sense for peers to negotiate at the beginning of a connection wh=
ether they are going to use wtxid- or txid-based, prior to announcing any t=
ransactions.=C2=A0 To achieve this, I propose in the BIP to send a message =
between receiving a VERSION message and prior to sending VERACK (to nodes a=
dvertising version at least 70016) to announce support for this new feature=
; if both sides send it then they each know to enable it on the link.=C2=A0=
 My thinking is that in general, it&#39;d be great to use messages sent bet=
ween VERSION and VERACK to negotiate features prior to fully initializing a=
 peer connection (it&#39;s sort of a natural way to extend what we might wa=
nt to send in a VERSION message, without breaking existing VERSION-message =
parsers).=C2=A0 However, I don&#39;t know whether inserting a message befor=
e VERACK would break any assumptions of other software on the network, or i=
f this is a problematic paradigm for some reason, so I&#39;d welcome feedba=
ck here.</div><div><br></div><div>Thanks,</div><div>Suhas</div></div>

--000000000000ec2aa6059f6bc548--