š
Original date posted:2017-09-13
š Original message:On Wed, Sep 13, 2017 at 08:27:36AM +0900, Karl Johan Alm via bitcoin-dev wrote:
> On Wed, Sep 13, 2017 at 4:57 AM, Mark Friedenbach via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> Without the limit I think we would be DoS-ed to dead
> >
> > 4MB of secp256k1 signatures takes 10s to validate on my 5 year old
> > laptop (125,000 signatures, ignoring public keys and other things that
> > would consume space). That's much less than bad blocks that can be
> > constructed using other vulnerabilities.
>
> Sidenote-ish, but I also believe it would be fairly trivial to keep a
> per UTXO tally and demand additional fees when trying to respend a
> UTXO which was previously "spent" with an invalid op count. I.e. if
> you sign off on an input for a tx that you know is bad, the UTXO in
> question will be penalized proportionately to the wasted ops when
> included in another transaction later. That would probably kill that
> DoS attack as the attacker would effectively lose bitcoin every time,
> even if it was postponed until they spent the UTXO. The only thing
> clients would need to do is to add a fee rate penalty ivar and a
> mapping of outpoint to penalty value, probably stored as a separate
> .dat file. I think.
Ethereum does something quite like this; it's a very bad idea for a few
reasons:
1) If you bailed out of verifying a script due to wasted ops, how did you know the
transaction trying to spend that txout did in fact come from the owner of it?
2) How do you verify that transactions were penalized correctly without *all*
nodes re-running the DoS script?
3) If the DoS is significant enough to matter on a per-node level, you're going
to have serious problems anyway, quite possibly so serious that the attacker
manages to cause consensus to fail. They can then spend the txouts in a block
that does *not* penalize their outputs, negating the deterrent.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170913/fe142009/attachment.sig>;
Peter Todd [ARCHIVE] /
npub1m2ā¦a2np2
2023-06-07 18:05:37
in reply to nevent1qā¦d8ka
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 18:05:37Event JSON
{
"id": "aaeeb1bb0b5a35c01452605a509d7eb3896fde4a8882209c1a3d5bd2295a2669",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686161137,
"kind": 1,
"tags": [
[
"e",
"0d97933d6393537f8afa1f55574e0ec2278e08b49a828e8a6bf1f6fff59c2613",
"",
"root"
],
[
"e",
"ef8e873f31e3a1ab6f9b0f970035c6a4b0789cc42e335cf784678864753c7fae",
"",
"reply"
],
[
"p",
"cf98d015f410ea690e93370543fcb2c3129303ca3921fd6d463206f557722518"
]
],
"content": "š
Original date posted:2017-09-13\nš Original message:On Wed, Sep 13, 2017 at 08:27:36AM +0900, Karl Johan Alm via bitcoin-dev wrote:\n\u003e On Wed, Sep 13, 2017 at 4:57 AM, Mark Friedenbach via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\u003e Without the limit I think we would be DoS-ed to dead\n\u003e \u003e\n\u003e \u003e 4MB of secp256k1 signatures takes 10s to validate on my 5 year old\n\u003e \u003e laptop (125,000 signatures, ignoring public keys and other things that\n\u003e \u003e would consume space). That's much less than bad blocks that can be\n\u003e \u003e constructed using other vulnerabilities.\n\u003e \n\u003e Sidenote-ish, but I also believe it would be fairly trivial to keep a\n\u003e per UTXO tally and demand additional fees when trying to respend a\n\u003e UTXO which was previously \"spent\" with an invalid op count. I.e. if\n\u003e you sign off on an input for a tx that you know is bad, the UTXO in\n\u003e question will be penalized proportionately to the wasted ops when\n\u003e included in another transaction later. That would probably kill that\n\u003e DoS attack as the attacker would effectively lose bitcoin every time,\n\u003e even if it was postponed until they spent the UTXO. The only thing\n\u003e clients would need to do is to add a fee rate penalty ivar and a\n\u003e mapping of outpoint to penalty value, probably stored as a separate\n\u003e .dat file. I think.\n\nEthereum does something quite like this; it's a very bad idea for a few\nreasons:\n\n1) If you bailed out of verifying a script due to wasted ops, how did you know the\ntransaction trying to spend that txout did in fact come from the owner of it?\n\n2) How do you verify that transactions were penalized correctly without *all*\nnodes re-running the DoS script?\n\n3) If the DoS is significant enough to matter on a per-node level, you're going\nto have serious problems anyway, quite possibly so serious that the attacker\nmanages to cause consensus to fail. They can then spend the txouts in a block\nthat does *not* penalize their outputs, negating the deterrent.\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 455 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170913/fe142009/attachment.sig\u003e",
"sig": "6cfaefc80f27d13e8ead7e45c2770732978e04da2adf5401308119fe4344f0a7245e98fc6486802ae4b4a9e03635343709236f92ebc72c4a938db7179351e9c9"
}