Re: [bitcoin-dev] OP_BEFOREBLOCKVERIFY - discussing and opcode that invalidates a spend path after a certain block

2021-06-11 Thread Russell O'Connor via bitcoin-dev
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 wit

Re: [bitcoin-dev] OP_BEFOREBLOCKVERIFY - discussing and opcode that invalidates a spend path after a certain block

2021-06-11 Thread James MacWhyte via bitcoin-dev
@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 passivel

Re: [bitcoin-dev] OP_BEFOREBLOCKVERIFY - discussing and opcode that invalidates a spend path after a certain block

2021-06-11 Thread Billy Tetrud via bitcoin-dev
> 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 connection

Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent

2021-06-11 Thread darosior via bitcoin-dev
> Note, I think that the tx mutation proposal relies on interactivity in the > worst-case scenario where a counterparty wants to increase its fee-bumping > output from the contract balance. This interactivity may lure a counterparty > to alway lock the worst-case fee-bumping reserve in the outpu