From: "David A. Harding" <dave@dtrt•org>
To: Jeremy Rubin <jeremy.l.rubin@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Sponsor transaction engineering, was Re: Thoughts on fee bumping
Date: Fri, 18 Feb 2022 21:09:31 +0000 [thread overview]
Message-ID: <0100017f0eab2640-c7be81bb-c1c5-4150-a65a-cadd78a8258f-000000@email.amazonses.com> (raw)
In-Reply-To: <CAD5xwhjYCrRU0+kJG0Pex2ga3rFxFQNyn0dX5+8io0hbEUSjsQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1241 bytes --]
On Tue, Feb 15, 2022 at 01:37:43PM -0800, Jeremy Rubin via bitcoin-dev wrote:
> Unfortunately, there are technical reasons for sponsors to not be monotone.
> Mostly that it requires the maintenance of an additional permanent
> TX-Index
Alternatively, you could allow a miner to include a sponsor transaction
in a later block than the sponsored transaction by providing an (SPV)
merkle inclusion proof that the sponsored transaction was a part of a
previous block on the same chain.[1]
This does raise the vbyte cost of including sponsor and sponsored
transactions in different blocks compared to including them both in the
same block, but I wonder if it mitigates the validity concern raised by
Suhas Daftuar in the previous sponsor transaction thread.
-Dave
[1] Bitcoin Core stores the complete headers chain, so it already has
the information necessary to validate such a proof (and the
`verifytxoutproof` RPC already does this). Utreexo-style nodes might
not store old headers to save space, but I presume they could store a
merkle-like commitment to all headers they previously validated and then
have utreexo proofs include the necessary headers and intermediate
hashes necessary to validate subsequent-block sponsor transactions.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-02-18 21:09 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-10 19:40 [bitcoin-dev] " James O'Beirne
2022-02-10 23:09 ` Greg Sanders
2022-02-10 23:44 ` darosior
2022-02-10 23:51 ` James O'Beirne
2022-02-11 6:51 ` darosior
2022-02-12 19:44 ` Billy Tetrud
2022-02-11 0:12 ` Matt Corallo
2022-02-14 19:51 ` James O'Beirne
2022-02-17 14:32 ` Anthony Towns
2022-02-17 18:18 ` James O'Beirne
2022-02-18 9:01 ` darosior
2022-02-18 0:35 ` Antoine Riard
2022-02-11 5:26 ` Antoine Riard
2022-02-14 20:28 ` James O'Beirne
2022-02-15 0:43 ` Antoine Riard
2022-02-15 17:09 ` Billy Tetrud
2022-02-15 20:24 ` Russell O'Connor
2022-02-15 20:53 ` James O'Beirne
2022-02-15 21:37 ` Jeremy Rubin
2022-02-18 21:09 ` David A. Harding [this message]
2022-02-15 21:38 ` Jeremy Rubin
2022-02-16 2:54 ` Billy Tetrud
2022-02-16 19:18 ` James O'Beirne
2022-02-16 20:36 ` Billy Tetrud
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=0100017f0eab2640-c7be81bb-c1c5-4150-a65a-cadd78a8258f-000000@email.amazonses.com \
--to=dave@dtrt$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jeremy.l.rubin@gmail$(echo .)com \
/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