On Fri, Sep 23, 2016 at 10:20 PM, Luke Dashjr via bitcoin-dev <[email protected]> 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). _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
