public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd.org>
To: Jeff Garzik <jgarzik@bitpay.com>
Cc: bitcoin-development@lists.sourceforge.net,
	Jeremy Spilman <jeremy.spilman@gmail.com>
Subject: Re: [Bitcoin-development] Anti DoS for tx replacement
Date: Thu, 18 Jul 2013 09:43:47 -0400	[thread overview]
Message-ID: <20130718134347.GB28234@petertodd.org> (raw)
In-Reply-To: <CAJHLa0M+LNuEa6j3RN-e1JLA2Q35-mjCo+AhOSJdoxBA6Vm1ow@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2038 bytes --]

On Thu, Jul 18, 2013 at 08:53:55AM -0400, Jeff Garzik wrote:
> On Thu, Jul 18, 2013 at 7:13 AM, Peter Todd <pete@petertodd.org> wrote:
> > Note that with OP_DEPTH we can remove the small chance of the payee
> > vanishing and putting the funds in limbo:
> 
> What are the costs, benefits, and risks associated with scripts no
> longer being stateless, as OP_DEPTH would seem to introduce?

Satoshi was worried that in the event of a re-org long chains of
transactions could become invalid and thus impossible to include in the
blockchain again, however that's equally possibly through tx mutability
or double-spends;(1) I don't think it's a valid concern in general. When
accepting any payment you need to take the chance of a re-org into
account, and if the payment is large enough it'll call for more confirms
on that basis. It does increase that (small) risk however and a client
may want to trace the transaction chain back a few steps when accepting
a very large payment in leu of just waiting for more confirms.

1) Also via non-standard transactions as SetBestChain() calls
mempool.accept() which still applies IsStandard(). We also recently
broke re-acceptance of transactions with dependencies as they are
currently added in reverse order, broken when Matt removed the
fIgnoreMissingInputs flag.


Not a problem limited to OP_DEPTH either: consider the following
probabalistic payment:

    PREVBLOCKHASH HASH n LESSTHAN VERIFY <pubkey> CHECKSIG

Obviously in a re-org the chance of it being succesfully included is
slim. (this example is simplistic and is vulnerable to double-spends in
a number of ways)


Mempool and relay code will have to take into account that a transaction
that can be included in the next block may not be possible to include in
the block after that for the purposes of protecting against tx-flood DoS
attacks - not an important issue unless we loosen IsStandard()

-- 
'peter'[:-1]@petertodd.org
0000000000000090344430e3956a709039288ceeb473fff6c1b68e70ee7169c4

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2013-07-18 13:44 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-20  1:48 [Bitcoin-development] Anti DoS for tx replacement Jeremy Spilman
2013-07-18 11:13 ` Peter Todd
2013-07-18 12:53   ` Jeff Garzik
2013-07-18 13:43     ` Peter Todd [this message]
2013-07-18 16:09   ` Peter Todd
  -- strict thread matches above, loose matches on Subject: below --
2013-04-20 20:51 Jeremy Spilman
2013-04-22 11:07 ` Mike Hearn
2013-04-23 12:40 ` John Dillon
2013-04-16 17:39 Mike Hearn
2013-04-16 18:43 ` Peter Todd
2013-04-17  9:48   ` Mike Hearn
2013-04-17 19:44     ` Alan Reiner
2013-04-18  6:07     ` John Dillon
2013-04-18  8:14       ` Peter Todd
2013-04-19  4:38         ` John Dillon
2013-04-19  4:55           ` Jeff Garzik
2013-04-18  8:32       ` Mike Hearn
2013-04-18  9:04         ` Peter Todd
2013-04-18  9:28           ` Peter Todd
2013-04-18  9:32             ` Mike Hearn
2013-04-18  9:28           ` Mike Hearn
2013-04-18  9:34             ` Mike Hearn
2013-04-18 10:08             ` Peter Todd
2013-04-18 10:19               ` Mike Hearn
2013-04-18 13:37                 ` Gavin Andresen
     [not found] ` <CAD0SH_WOG8jQvzsNzwud3fYjaxqTJo0CS7yP6XZeKvap_yqtqg@mail.gmail.com>
2013-04-17  9:19   ` Mike Hearn

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=20130718134347.GB28234@petertodd.org \
    --to=pete@petertodd.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=jeremy.spilman@gmail.com \
    --cc=jgarzik@bitpay.com \
    /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