I've thought of a third mitigation I think might be sufficient for you,
Russell, even if neither changing what receivers of coins define as a
finalized transaction nor disallowing block height from be specified by the
script witness are not sufficient for some reason.
Consider a rule increasing
> 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,
On Sat, Jun 12, 2021 at 3:59 AM Billy Tetrud 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
> 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
On Fri, Jun 11, 2021 at 7:12 AM James MacWhyte 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
@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
> one can design a wallet to passively take advantage of reorgs
It does sound like this is the central issue. I can certainly see that it's
materially different than current double spending ability. Double spending
via reorgs today requires either active participation and above-average
As it stands today, in order to double spend a transaction during a reorg,
one must take an active role of recognizing that a reorg has happened, hope
that the new branch has completely omitted your spending transaction, and
then quickly broadcast a replacement transaction with a higher fee to
@Russell In that thread, you quoted Satoshi there, but neither he nor you
really deeply explained the concern. Would you mind elaborating on a
situation that calls for concern here? Some deeper explanation of the
"reorg safety" property would also be helpful. I'd very much like to know
what your
This is a continuation of the thread at
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018760.html
on this topic.
I still remain unconvinced that we ought to give up on the "reorg safety"
property that is explicitly part of Bitcoin's design.
On Thu, Jun 10, 2021 at 1:56 PM
Hi Everyone,
I'd like to open a discussion of an opcode I call OP_BEFOREBLOCKVERIFY
(OP_BBV) which is similar to ones that have been discussed before (eg
OP_BLOCKNUMBER). The opcode is very simple: the it takes as a parameter a
number representing a block height, and marks the transaction invalid
11 matches
Mail list logo
