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
📝 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