From: Suhas Daftuar <sdaftuar@gmail•com>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] A proposal for WTXID-based transaction relay
Date: Tue, 25 Feb 2020 14:48:23 -0500 [thread overview]
Message-ID: <CAFp6fsFzRT=iYM=YK6hbhD3WB0Scoo8hDT-tOcjuyOFsBc00gw@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2505 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 3175 bytes --]
reply other threads:[~2020-02-25 19:48 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAFp6fsFzRT=iYM=YK6hbhD3WB0Scoo8hDT-tOcjuyOFsBc00gw@mail.gmail.com' \
--to=sdaftuar@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox