From: Jeremy Spilman <jeremy.spilman@gmail•com>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Anti DoS for tx replacement
Date: Sat, 20 Apr 2013 13:51:23 -0700 [thread overview]
Message-ID: <CA+CODZF_kVoKcPjPgpfnEH4PBFfLJqS7SuvsRG_DRJroo3gcLA@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2330 bytes --]
I was discussing this with petertodd a couple days ago and we were thinking
the sequence I sent yesterday was usable today. I tried getting it to work
on test-net but the final transaction closing the channel was not being
accepted into the mempool beacause "ERROR: CTxMemPool::accept() : inputs
already spent"
But I was talking with sipa and gmaxwell on IRC about it, and sipa reminded
me; Test-Net implements IsStandard() to allow the non-final "refund" TX
into the mempool, but then doesn't allow it to be replaced, Main-Net
implements IsStandard() to *reject* non-final transactions in the first
place.
Therefore, this actually will work on Main-Net today, since the refund TX
won't even be allowed into the mempool until it's final, the AP is free to
sign and broadcast its final TX without any replacement. Of course, if the
AP waits too long, the user can get their Refund into the mempool and the
AP's [higher seq] version will be locked out.
This may be a case where Test-Net is in a "bad" state, by allowing
non-final TXs into the pool, but not allowing replacement, you get an
intermediate state which neither matches Main-Net behavior, nor implements
behavior which would ever be deployed to Main-Net as-is.
The current Main-Net behavior is actually very well suited for this
application. Any application that can be reduced to two instances of a Tx,
namely one non-final, and one final which is updated internally between the
parties, works very well under the current Main-Net rules.
If you set the nLockTime of the refund to be several days after the
scheduled closing time of the channel, it would be quite challenging to get
the Refund TX into the blockchain *despite* a final broadcast TX from the
AP. Since the vast majority of Main-Net won't even accept it, the attacker
would have to distribute the TX to any miner who could include the AP's
transaction in a block between now and when the refund becomes final, and
convince them all to not include the perfectly valid, fees paid, final,
nSeq=MAX, nLockTime=0 transaction from the AP. Demonstrating that level of
coordination would act substantially against the best interests of the
miners, to say the least.
This proposal still suffers from any malleability weakness, where the
user's refund could be invalidated by a miner changing the TxID of TX1.
[-- Attachment #2: Type: text/html, Size: 2917 bytes --]
next reply other threads:[~2013-04-20 20:51 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-20 20:51 Jeremy Spilman [this message]
2013-04-22 11:07 ` Mike Hearn
2013-04-23 12:40 ` John Dillon
-- strict thread matches above, loose matches on Subject: below --
2013-04-20 1:48 Jeremy Spilman
2013-07-18 11:13 ` Peter Todd
2013-07-18 12:53 ` Jeff Garzik
2013-07-18 13:43 ` Peter Todd
2013-07-18 16:09 ` Peter Todd
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=CA+CODZF_kVoKcPjPgpfnEH4PBFfLJqS7SuvsRG_DRJroo3gcLA@mail.gmail.com \
--to=jeremy.spilman@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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