On Mon, Oct 31, 2022 at 09:02:02AM -0400, Suhas Daftuar via bitcoin-dev wrote:
Sending this email for the sake of repeating a point I made on GitHub for the
mailing list audience:
> AJ,
>
> Thanks for the thoughtful post. I think your observations about how we view
> mempool policy in the
Hi Johan,
I haven't really been able to find a precise technical explanation of the
"utxo teleport" scheme, but after thinking about your example use cases a
bit, I don't think the scheme is actually sound. Consider that the scheme
attempts to target transmitting "ownership" to a UTXO. However,
Good morning Trey,
> * something like OP_PUSHSCRIPT which would remove the need for the
> introspection the the prevout's script and avoids duplicating data in
> the witness
> * some kind of OP_MERKLEUPDATEVERIFY which checks a merkle proof for a
> leaf against a root and checks if replacing the
On Fri, Nov 4, 2022 at 4:04 PM Trey Del Bonis via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Instead of that approach, I assume we have fairly granular transaction
> introspection opcodes from a list in Elements [2] (which seem like they
> aren't actually used in mainnet
Hi all, I figured I could answer some of these rollup questions,
There's a few different possibilities to make rollups work that have
different tradeoffs. The core construction I worked out in [1] involves
a quine-ish recursive covenant that stores some persistent "state" as
part of the
Peter,
There's nothing special about a "full-rbf transaction" other than the
fact
that it's replacing a previously broadcast transaction that didn't
signal
replacement.
Thanks, this is a piece I haven't seen. It sounds like "full-rbf"
policy is fundamentally different from BIP125, where
