ð
Original date posted:2016-10-02
ð Original message:On Sun, Oct 2, 2016 at 6:46 PM, Russell O'Connor via bitcoin-dev <
bitcoin-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161002/c6349d29/attachment-0001.html>;
Sergio Demian Lerner [ARCHIVE] /
npub1fvâŠ3vq7f
2023-06-07 17:53:43
in reply to nevent1qâŠa32x
Author Public Key
npub1fvuxqdqg7klqqgy3yy8gdxjv4phu92sll5y8zqm2qe5qdrhxymhqf3vq7fPublished at
2023-06-07 17:53:43Event JSON
{
"id": "037631359ff5e060ff5469aa2e4de14777ee6882a49786a63b1ebc3fb611909a",
"pubkey": "4b38603408f5be002091210e869a4ca86fc2aa1ffd0871036a0668068ee626ee",
"created_at": 1686160423,
"kind": 1,
"tags": [
[
"e",
"a0719e105373a31b19331be2ab9915ba509ea0ec8469edd3808978e2d85d8297",
"",
"root"
],
[
"e",
"822cf04d3f9a5b25949e34391a802b566ca2c3d1880205df76f37b0d7feff9e0",
"",
"reply"
],
[
"p",
"6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d"
]
],
"content": "ð
Original date posted:2016-10-02\nð Original message:On Sun, Oct 2, 2016 at 6:46 PM, Russell O'Connor via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e\n\u003e But I would argue that in this scenario, the only way it\n\u003e\u003e would become invalid is the equivalent of a double-spend... and therefore\n\u003e\u003e it\n\u003e\u003e may be acceptable in relation to this argument.\n\u003e\u003e\n\u003e\n\u003e The values returned by OP_COUNT_ACKS vary in their exact value depending\n\u003e on which block this transaction ends up in. While the proposed use of this\n\u003e operation is somewhat less objectionable (although still objectionable to\n\u003e me), nothing stops users from using OP_EQUALVERIFY and and causing their\n\u003e transaction fluctuate between acceptable and unacceptable, with no party\n\u003e doing anything like a double spend. This is a major problem with the\n\u003e proposal.\n\u003e\n\nTransactions that redeem an output containing (or referencing by means of\nP2WSH) an OP_COUNT_ACKS are not broadcast by the network. That means that\nthe network cannot be DoS attacked by flooding with a transaction that will\nnot verify due to being too late.\nThe only parties that can include the redeem transaction are the miners\nthemselves.\nTherefore I see no problem that an OP_COUNT_ACKS scriptSig transaction is\ninvalidated after the liveness times expires.\nIf there is no expiration, then polls can last forever and the system fails\nto provide DoS protection for block validation since active polls can\naccumulate forever.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161002/c6349d29/attachment-0001.html\u003e",
"sig": "4e772a4cf8d4ac6039755a28e6e27724f3a7f22dc20a4a30ac603b3f6b9b62a1e4a023823729426298ecef9b1fc2ee4c3721425a78732fe9b3d99c976d566850"
}