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
outb
@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 th
Hi Lloyd,
Thanks for this tx mutation proposal extending the scope of fee-bumping
techniques. IIUC, the serves as a pointer to increase the
output amount by value to recover the recompute the transaction hash
against which the original signature is valid ?
Let's do a quick analysis of this schem
> So something like
`or(and(pk(FB),pk(A)),and(pk(FB),pk(B)),and(pk(FB),pk(C)))` with each `or`
in their own leaf? I think it works, but only if the keys `A`, `B`, `C` are
"hot", as in available to the
fee-bumper. For Revault it means introducing a key for each watchtower in
the vaults descriptors,
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 Bil
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
Hi,
Another thing to consider when comparing these two techniques is anti-fee
sniping protection. If you are going to feebump directly
your revocation transaction by adding inputs to it, the nLockTime has already
been signed in advance. Therefore your are sponsoring
a transaction that could be i
See
https://gist.github.com/chris-belcher/903feab321bf41055c91eaec46581e89
for the latest version of this BIP.
BIP: TBD
Layer: Applications
Title: Anti-fee-sniping protection with nSequence in taproot
transactions to improve privacy for off-chain protocols
Author: Chris Belcher
Statu
