public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Karl Johan Alm <karljohan-alm@garage.co.jp>
To: Mark Friedenbach <mark@friedenbach.org>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Merkle branch verification & tail-call semantics for generalized MAST
Date: Wed, 13 Sep 2017 08:27:36 +0900	[thread overview]
Message-ID: <CALJw2w49t5Wt1Czf4VTNj10opzPOS8ZDrRgoAwmeVFTeWWzBLg@mail.gmail.com> (raw)
In-Reply-To: <61D84B62-0F3F-48E1-B749-F628AD91BC12@friedenbach.org>

On Wed, Sep 13, 2017 at 4:57 AM, Mark Friedenbach via bitcoin-dev
<bitcoin-dev@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.


  reply	other threads:[~2017-09-12 23:35 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-07  0:38 [bitcoin-dev] Merkle branch verification & tail-call semantics for generalized MAST Mark Friedenbach
2017-09-08  9:21 ` Johnson Lau
2017-09-12  2:03   ` Mark Friedenbach
2017-09-12  2:13     ` Bryan Bishop
2017-09-12  8:55     ` Johnson Lau
2017-09-12 19:57       ` Mark Friedenbach
2017-09-12 23:27         ` Karl Johan Alm [this message]
2017-09-13  9:41           ` Peter Todd
2017-09-11 20:37 ` Adán Sánchez de Pedro Crespo
2017-09-19  0:46 ` Mark Friedenbach
2017-09-19  3:09   ` [bitcoin-dev] cleanstack alt stack & softfork improvements (Was: Merkle branch verification & tail-call semantics for generalized MAST) Luke Dashjr
2017-09-19  7:33     ` Mark Friedenbach
2017-09-22 20:32       ` Sergio Demian Lerner
2017-09-22 21:11         ` Mark Friedenbach
2017-09-22 21:32           ` Sergio Demian Lerner
2017-09-22 21:39             ` Mark Friedenbach
2017-09-22 21:54               ` Sergio Demian Lerner
2017-09-22 22:07                 ` Mark Friedenbach
2017-09-22 22:09                 ` Pieter Wuille
2021-04-09  8:15                   ` [bitcoin-dev] maximum block height on transaction Erik Aronesty
2021-04-09 11:39                     ` Russell O'Connor
2021-04-09 15:54                       ` Jeremy
2021-04-12 20:04                         ` Billy Tetrud
2021-04-16  4:24                           ` ZmnSCPxj
2021-05-03  2:30                             ` ZmnSCPxj
2017-09-20  5:13     ` [bitcoin-dev] cleanstack alt stack & softfork improvements (Was: Merkle branch verification & tail-call semantics for generalized MAST) Johnson Lau
2017-09-20 19:29       ` Mark Friedenbach
2017-09-21  3:58         ` Johnson Lau
2017-09-21  4:11       ` Luke Dashjr
2017-09-21  8:02         ` Johnson Lau
2017-09-21 16:33           ` Luke Dashjr
2017-09-21 17:38             ` Johnson Lau
2017-09-30 23:23 ` [bitcoin-dev] Merkle branch verification & tail-call semantics for generalized MAST Luke Dashjr
2017-09-30 23:51   ` Mark Friedenbach
2017-10-02 17:15     ` Russell O'Connor
2017-10-28  4:40 ` Mark Friedenbach
2017-11-01  8:43   ` Luke Dashjr
2017-11-01 15:08     ` Mark Friedenbach
2017-11-04  7:59       ` Luke Dashjr

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALJw2w49t5Wt1Czf4VTNj10opzPOS8ZDrRgoAwmeVFTeWWzBLg@mail.gmail.com \
    --to=karljohan-alm@garage.co.jp \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=mark@friedenbach.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox