Gregory Maxwell [ARCHIVE] on Nostr: 📅 Original date posted:2016-09-23 📝 Original message:On Fri, Sep 23, 2016 at ...
📅 Original date posted:2016-09-23
📝 Original message:On Fri, Sep 23, 2016 at 10:20 PM, Luke Dashjr via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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.
There is a fungibility hit... right now, absent double spends (and
privacy issues), every coin you might get paid is equal.
With this script feature as described, you could get paid a coin which
has one of these in its recent past, pinning the block immediately
before it. A reorg long enough to remove that block-- due to an
attack, or an ordinary block race, or some kind of consensus glitch
(like we had in March 2013 or around the activation of BIP65)-- is
_guaranteed_ to invalidate those coins, even without any double spend.
If the scheme doesn't do as I suggest and prevent over-eager usage
(perhaps 100 is too much, I just decided to match coinbases); then it
should probably have a consensus enforced explicit "maximum survivable
reorg" that is traced along with the outputs, so that someone who
received exposed coins could handle it sensibly.
Just for plain engineering reasons, I still think it is important to
now allow overly short back references. If the reference has to be a
few blocks back we don't need to worry about short forks breaking
propagation, and simple mempool handling like purging all CBAH
transactions on a large reorg would work fine. It need not be so long
as to implicate Petertodd's concern that you could only use it where
it wouldn't matter. (Though I also disagree that a depth of 100
achieves that, consider persistent chain forks).
📝 Original message:On Fri, Sep 23, 2016 at 10:20 PM, Luke Dashjr via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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.
There is a fungibility hit... right now, absent double spends (and
privacy issues), every coin you might get paid is equal.
With this script feature as described, you could get paid a coin which
has one of these in its recent past, pinning the block immediately
before it. A reorg long enough to remove that block-- due to an
attack, or an ordinary block race, or some kind of consensus glitch
(like we had in March 2013 or around the activation of BIP65)-- is
_guaranteed_ to invalidate those coins, even without any double spend.
If the scheme doesn't do as I suggest and prevent over-eager usage
(perhaps 100 is too much, I just decided to match coinbases); then it
should probably have a consensus enforced explicit "maximum survivable
reorg" that is traced along with the outputs, so that someone who
received exposed coins could handle it sensibly.
Just for plain engineering reasons, I still think it is important to
now allow overly short back references. If the reference has to be a
few blocks back we don't need to worry about short forks breaking
propagation, and simple mempool handling like purging all CBAH
transactions on a large reorg would work fine. It need not be so long
as to implicate Petertodd's concern that you could only use it where
it wouldn't matter. (Though I also disagree that a depth of 100
achieves that, consider persistent chain forks).