From: Jeremy <jlrubin@mit•edu>
To: Antoine Riard <antoine.riard@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] A Replacement for RBF and CPFP: Non-Destructive TXID Dependencies for Fee Sponsoring
Date: Sat, 19 Sep 2020 12:46:25 -0700 [thread overview]
Message-ID: <CAD5xwhgw4Hsco73B1D5+EafXFbcr3227MM2ZNPtycyv2TS-n7g@mail.gmail.com> (raw)
In-Reply-To: <CALZpt+EAWbPWh_knT7yDdPT396jEL1g+XSEv1JALuwaJVqNS7w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1851 bytes --]
Antoine,
Yes I think you're a bit confused on where the actual sponsor vector is. If
you have a transaction chain A->B->C and a sponsor S_A, S_A commits to txid
A and A is unaware of S.
W.r.t your other points, I fully agree that the 1-to-N sponsored case is
very compelling. The consensus rules are clear that sponsor commitments are
non-rival, so there's no issue with allowing as many sponsors as possible
and including them in aggregate. E.g., if S_A and S'_A both sponsor A with
feerate(S*) > feerate(A), there's no reason not to include all of them in a
block. The only issue is denial of service in the mempool. In the future,
it would definitely be desirable to figure out rules that allow mempools to
track both multiple sponsors and multiple sponsor targets. But in the
interest of KISS, the current policy rules are designed to be minimally
invasive and maximally functional.
In terms of location for the sponsor vector, I'm relatively indifferent.
The annex is a possible location, but it's a bit odd as we really only need
to allow one such vector per tx, not one per input, and one per input would
enable some new use cases (maybe good, maybe bad). Further, being in the
witness space would mean that if two parties create a 2 input transaction
with a desired sponsor vector they would both need to specify it as you
can't sign another input's witness data. I wholeheartedly agree with the
sentiment though; there could be a more efficient place to put this data,
but nothing jumps out to me as both efficient and simple in implementation
(a new tx-level field sounds like a lot of complexity).
> n >=1 ? I think you can have at least one vector and this is matching the
code
yes, this has been fixed in the gist (cred to Dmitry Petukhov for pointing
it out first), but is correct in the code. Thank you for your careful
reading.
[-- Attachment #2: Type: text/html, Size: 3282 bytes --]
next prev parent reply other threads:[~2020-09-19 19:46 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-19 0:51 Jeremy
2020-09-19 1:39 ` Cory Fields
2020-09-19 16:16 ` Jeremy
2020-09-19 13:37 ` David A. Harding
2020-09-19 15:01 ` nopara73
2020-09-19 16:30 ` Jeremy
2020-09-19 17:24 ` David A. Harding
2020-09-19 18:39 ` Antoine Riard
2020-09-19 19:13 ` Antoine Riard
2020-09-19 19:46 ` Jeremy [this message]
2020-09-20 23:10 ` Antoine Riard
2020-09-21 14:52 ` David A. Harding
2020-09-21 16:27 ` Jeremy
2020-09-21 23:40 ` Antoine Riard
2020-09-22 18:05 ` Suhas Daftuar
2020-09-23 22:10 ` Jeremy
2020-09-24 4:22 ` Dmitry Petukhov
2020-09-22 6:24 ArmchairCryptologist
2020-09-22 13:52 ` Antoine Riard
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=CAD5xwhgw4Hsco73B1D5+EafXFbcr3227MM2ZNPtycyv2TS-n7g@mail.gmail.com \
--to=jlrubin@mit$(echo .)edu \
--cc=antoine.riard@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