If someone uses OP_EQUALVERIFY after OP_COUNT_ACKS then the transaction probably won't be able to be included at a different height.
On Oct 2, 2016 19:16, "Sergio Demian Lerner" <sergio.d.ler...@gmail.com> wrote: > It can be included at another block at a differnt height. It can be > included anytime during the liveness period which starts 100 blocks later > than the poll period ends. I'm reading the BIP now and it's true that this > is not enterily clear. I will try to clarify. > > > On Sun, Oct 2, 2016 at 7:58 PM, Russell O'Connor <rocon...@blockstream.io> > wrote: > >> A related problem is that if this transaction is reorged out during an >> innocent reorg, one that doesn't involve a double spend, the transaction >> may never get back in unless it occurs at exactly the same height, which >> is not guaranteed. >> >> This affects fungabity of coins generated from these transactions. >> >> On Oct 2, 2016 18:37, "Sergio Demian Lerner" <sergio.d.ler...@gmail.com> >> wrote: >> >>> >>> >>> On Sun, Oct 2, 2016 at 6:46 PM, Russell O'Connor via bitcoin-dev < >>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>> >>>> >>>> But I would argue that in this scenario, the only way it >>>>> would become invalid is the equivalent of a double-spend... and >>>>> therefore it >>>>> may be acceptable in relation to this argument. >>>>> >>>> >>>> The values returned by OP_COUNT_ACKS vary in their exact value >>>> depending on which block this transaction ends up in. While the proposed >>>> use of this operation is somewhat less objectionable (although still >>>> objectionable to me), nothing stops users from using OP_EQUALVERIFY and and >>>> causing their transaction fluctuate between acceptable and unacceptable, >>>> with no party doing anything like a double spend. This is a major problem >>>> with the proposal. >>>> >>> >>> Transactions that redeem an output containing (or referencing by means >>> of P2WSH) an OP_COUNT_ACKS are not broadcast by the network. That means >>> that the network cannot be DoS attacked by flooding with a transaction that >>> will not verify due to being too late. >>> The only parties that can include the redeem transaction are the miners >>> themselves. >>> Therefore I see no problem that an OP_COUNT_ACKS scriptSig transaction >>> is invalidated after the liveness times expires. >>> If there is no expiration, then polls can last forever and the system >>> fails to provide DoS protection for block validation since active polls can >>> accumulate forever. >>> >>> >>> >>> >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
