From: Peter Todd <pete@petertodd•org>
To: bitcoin-development@lists•sourceforge.net
Subject: [Bitcoin-development] Replace-by-fee scorched-earth without child-pays-for-parent
Date: Mon, 28 Apr 2014 08:02:09 -0400 [thread overview]
Message-ID: <20140428120209.GJ20078@savin> (raw)
[-- Attachment #1: Type: text/plain, Size: 2704 bytes --]
Someone who wanted to remain anonymous sent me in this idea, which I'll
admit I'm kicking myself for not having thought of earlier. They sent
me this hash so they can claim credit for it later should they choose to
reveal their identity:
bb0de552f81fa356b99fbeef65fa532bb58111184efee2cbe92f66509af8d151
When Alice wants to pay Bob x bitcoins, rather than creating a single
transaction, tx1, that does that, she creates a pair of transactions,
with the second, tx2, spending the same inputs and an input provided by
Bob, but paying x*k bitcoins to fees. Should Bob detect a double-spend
he simply signs the extra input, making it clear that he intended for
the countermeasure to be deployed, and broadcasts tx2.
This mechanism has two advantages: 1) child-pays-for-parent isn't
required at avoiding changes to the relaying code and letting the
counter-transaction propagate quickly. 2) k can be adjusted such that
Alice is guaranteed to be worse off for attempting a double-spend even
taking into account the probability of getting away with it. For
instance, right now if just, say, Eligius adopted replace-by-fee a k
value of 20 would still make double-spends unprofitable.
However it does require payment protocol support. This lead me to
realize that if Alice signs all her inputs with the ANYONECANPAY sighash
bit set Bob can get the same effect by adding his own inputs to bump the
effective fee. While of course the funds to do so come out of his own
pocket, they are balanced out by the payment to him, with the net effect
being the same as the child-pays-for-parent version. Additionally in the
common case of "Bob would like Alice's transaction to go through sooner"
this also gives Bob the flexibility to add small sized inputs at will to
bump fees. (or for that matter Alice, giving a small privacy boost)
Using ANYONECANPAY does have one disadvantage in that transactions using
it are always malleable. However an "attacker" doing so is forced to
spend funds to do that. Secondly after the recent malleability attacks
wallet handling of malleability-related problems has greatly improved.
Finally it's worth noting how the k-overpaying version of scorched-earth
gives Finney attacking(1) miners - such as BitUndo - incentives to
defect knowing that they can earn significantly more fees by publishing
their supposedly secret transactions to the p2p network. Equally even in
the ANYONECANPAY version merchants may decide that discouraging fraud is
worth an overpayment.
1) https://bitcointalk.org/index.php?topic=3441.msg48384#msg48384
--
'peter'[:-1]@petertodd.org
0000000000000000603b189f99cf2a95ce01835596b5d5fbd8c5725c11f504ee
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]
reply other threads:[~2014-04-28 12:02 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20140428120209.GJ20078@savin \
--to=pete@petertodd$(echo .)org \
--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