From: "Russell O'Connor" <roconnor@blockstream•com>
To: James MacWhyte <macwhyte@gmail•com>
Cc: Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
Billy Tetrud <billy.tetrud@gmail•com>
Subject: Re: [bitcoin-dev] OP_BEFOREBLOCKVERIFY - discussing and opcode that invalidates a spend path after a certain block
Date: Fri, 11 Jun 2021 07:43:22 -0400 [thread overview]
Message-ID: <CAMZUoKmytZm5boBKSYbrJdNa0LduxtTyUUheq=tjD1J_GO0TjA@mail.gmail.com> (raw)
In-Reply-To: <CAH+Axy7b8MS92ZeMnPx-TosvNzRv9=34UDQ9ia-fxeLzO_A0+Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2912 bytes --]
On Fri, Jun 11, 2021 at 7:12 AM James MacWhyte <macwhyte@gmail•com> wrote:
> @Billy I like the idea. It is very obvious how useful an opcode like this
> would be! (My background is in wallet implementation)
>
> @Russell I do understand your concerns of monotonism, however I'm having a
> hard time really coming up with an attack vector. You said "one can design
> a wallet to passively take advantage of reorgs by always spending through
> an OP_BBV that is on the verge of becoming invalid." Unless I'm mistaken,
> this means you would need to send yourself a fresh transaction using OP_BBV
> set to, say, 2 blocks in the future, then immediately spend that output in
> a new payment to someone else and hope a reorg happens. Does this mean the
> theoretical double-spend wallet you are proposing would have to send two
> transactions every time you make a single payment, doubling the transaction
> fees and adding more uncertainty around when the second transaction would
> get confirmed?
>
Assuming the proposal is rewritten to place the maxheight into the taproot
annex in order to address the issue with caching of script validity, then
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. If the
payment doesn't make it into the next block, then resign it with the annex
incremented to the next block, and repeat.
> In a normal double spend scenario, there is no cost to a failed attempt,
> but much to gain from a success. With your design, there is a real cost to
> every single attempt (transaction fees) and no evidence that the rate of
> success would be higher (you still have to bet on the reorg not including
> your transaction in the first few blocks). It sounds like this new system
> would actually be less attractive to double spenders than the current model!
>
> I also agree with Billy's idea for relay rules. We already have abusable
> chain rules (e.g. a tx can be included in a block with 0 transaction fee
> [spam?]) but we add protection with relay rules (e.g. minimum fee to
> relay). I don't see how this would be any different, if the chain rules
> only enforced the block height for confirmation and the relay rules forced
> a minimum OP_BBV value in order to protect against reorg double spends.
>
The inclusion of a tx with 0 transaction fee in a block is not in of itself
an abuse. There is nothing wrong with blocks containing such
transactions. The *relay* of 0 transaction fee transactions is what is an
abuse because it allows one to usurp Bitcoin's gossip network for their own
arbitrary communications platform without cost. Most Bitcoin users aren't
signing up for being a usenet provider. So, by policy, nodes require a
cost to relay transactions so that broadcasting isn't free. Even when that
price is paid to someone else, it still is an effective limitation on abuse.
[-- Attachment #2: Type: text/html, Size: 3513 bytes --]
next prev parent reply other threads:[~2021-06-11 11:43 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 [this message]
2021-06-12 7:59 ` Billy Tetrud
2021-06-12 15:58 ` Russell O'Connor
2021-06-12 18:48 ` Billy Tetrud
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='CAMZUoKmytZm5boBKSYbrJdNa0LduxtTyUUheq=tjD1J_GO0TjA@mail.gmail.com' \
--to=roconnor@blockstream$(echo .)com \
--cc=billy.tetrud@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=macwhyte@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