From: Billy Tetrud <billy.tetrud@gmail•com>
To: "Russell O'Connor" <roconnor@blockstream•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_BEFOREBLOCKVERIFY - discussing and opcode that invalidates a spend path after a certain block
Date: Sat, 12 Jun 2021 11:48:24 -0700 [thread overview]
Message-ID: <CAGpPWDbcnBU62VCym_qS6Xu=nw59BO1Kf31N-S2ckQxU4rjbhg@mail.gmail.com> (raw)
In-Reply-To: <CAMZUoKkaRA5mYrpKY1T31qZtHQVAVwSGujf_bJXrj34FES2Drw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4535 bytes --]
> I'll just send my about-to-expire transactions directly to miners and
they will probably mine them because they are, in fact, valid, and pay
fees. Why wouldn't they mine it?
You've misunderstood me. When I said "change what counts as finalization",
what I meant is for the receiver of coins, not for mining or relay. For
example, if you buy coffee with an OP_BBV output that expires in the next
block, the merchant will be able to see that there's one confirmation on
your transaction. But they should also be able to see a warning saying that
the transaction has not finalized and they must wait for 6 confirmations
before treating payment as complete. This way, in the case that a reorg
happens and it doesn't contain the transaction, the merchant will not have
given the coffee yet, and their software will be able to tell them that the
payment has been reversed.
> I think the RBF flag ought to be removed from consideration and every
transaction should be considered RBFable
I agree with that. Making the assumption that a non-RBF transaction won't
be replaced isn't a great assumption.
> This indirection is how OP_CLTV and OP_CSV work
I see. Thanks for the explanation.
On Sat, Jun 12, 2021 at 8:58 AM Russell O'Connor <roconnor@blockstream•com>
wrote:
>
> On Sat, Jun 12, 2021 at 3:59 AM Billy Tetrud <billy.tetrud@gmail•com>
> wrote:
>
>> > taproot annex
>>
>> From what I can tell, the annex is basically additional inputs to a
>> script that might have additional constraints put on it. Is that right? I
>> don't quite follow how moving the max height to the annex helps script
>> caching here. I wasn't able to find much information on how the annex is
>> envisioned to be used. Would you mind elaborating on how this would work?
>>
>> Also, I think the proposal as it stands already addresses script caching
>> (in the Transaction Evaluation section
>> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblockverify.md#transaction-evaluation>).
>> The result of the script can be cached as long as the cache item also
>> contains information requiring just the OP_BBV to be re-evaluated (for the
>> relevant block).
>>
>
> The normal approach for this problem would be a design that adds an "annex
> field" (where the details on how to delimit annex fields is not yet
> standardized) for a maxheight value, and add a consensus rule that
> transaction with one (or more?) maxheight fields are invalid in blocks
> whose height exceeds this (or any) maxheight value. Then you could/would
> add an OP code to push a copy of the (smallest) maxheight value from the
> annex onto the stack or maybe an opcode to compare a stack item with this
> (every) maxheight value from the annex. This indirection is how OP_CLTV
> and OP_CSV work and this indirection makes script validity cacheable
> because script remains a function of the transaction data only. Since
> transaction data doesn't change, neither does the outcome of script
> evaluation. The rule that invalidates late transactions looks only at the
> annex and is independent of any script evaluation considerations.
>
>
>> > this auto-double-spend wallet would send every payment with an annex value
>> that limits the payment to being valid only up to the next block
>>
>> One possible solution to that would be to require that the input to
>> OP_BBV to be in the script itself and not originate from the witness.
>>
>> Regardless, I think the ideal solution is to not have any of these such
>> rules if we can simply change the definition for what counts as
>> finalization to account for the fact that BBV transactions mined close to
>> their expiration. Is there a reason this finalization-redefinition is not
>> an adequate solution?
>>
>
> Generally speaking, you cannot solve security problems through optional
> and completely voluntary transaction relay policy. I'll just send my
> about-to-expire transactions directly to miners and they will probably mine
> them because they are, in fact, valid, and pay fees. Why wouldn't they
> mine it?
>
> (Yes, I know this logic also applies to RBF flagged transactions. Indeed,
> you cannot rely on an RBF flag to prevent double spending, Yes I think the
> RBF flag ought to be removed from consideration and every transaction
> should be considered RBFable. Maybe that even happens to be my own node's
> relay policy.)
>
> I apologize, but I don't think I have further time to engage in an idea
> that I don't consider likely to achieve broad community support.
>
[-- Attachment #2: Type: text/html, Size: 5771 bytes --]
next prev parent reply other threads:[~2021-06-12 18:48 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-10 17:35 Billy Tetrud
2021-06-10 18:35 ` Russell O'Connor
2021-06-10 22:19 ` Billy Tetrud
2021-06-10 23:20 ` Russell O'Connor
2021-06-11 5:59 ` Billy Tetrud
2021-06-11 11:12 ` James MacWhyte
2021-06-11 11:43 ` Russell O'Connor
2021-06-12 7:59 ` Billy Tetrud
2021-06-12 15:58 ` Russell O'Connor
2021-06-12 18:48 ` Billy Tetrud [this message]
2021-06-13 22:12 ` 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='CAGpPWDbcnBU62VCym_qS6Xu=nw59BO1Kf31N-S2ckQxU4rjbhg@mail.gmail.com' \
--to=billy.tetrud@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=roconnor@blockstream$(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