What is Nostr?
Luke Dashjr [ARCHIVE] /
npub1tfk…fq0n
2023-06-07 17:53:34
in reply to nevent1q…whn9

Luke Dashjr [ARCHIVE] on Nostr: 📅 Original date posted:2016-09-23 📝 Original message:In the innocent use case ...

📅 Original date posted:2016-09-23
📝 Original message:In the innocent use case of this opcode, a double-spend has already occurred,
and this should be a strict improvement. In the non-innocent abuse of this
opcode, I don't see that it's any worse than simply double-spending.

Would this proposal be better or otherwise more acceptable, if a specified
height more recent than 100 blocks deep causes the script to fail? This would
increase delays in recovering the double-spend situation of course... but less
than 24h.

Luke


On Friday, September 23, 2016 1:43:15 PM Russell O'Connor wrote:
> I believe Bitcoin currently enjoys the property that during an "innocent"
> re-org, i.e. a reorg in which no affected transactions are being double
> spent, all affected transactions can always eventually get replayed, so
> long as the re-org depth is less than 100.
>
> My concern with this proposed operation is that it would destroy this
> property.
>
> On Fri, Sep 23, 2016 at 5:57 AM, Luke Dashjr via bitcoin-dev <
>
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> > This BIP describes a new opcode (OP_CHECKBLOCKATHEIGHT) for the Bitcoin
> > scripting system to address reissuing bitcoin transactions when the coins
> > they
> > spend have been conflicted/double-spent.
> >
> > https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki
> >
> > Does this seem like a good idea/approach?
> >
> > Luke
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Author Public Key
npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0n