public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [Bitcoin-development] Replace-by-fee scorched-earth without child-pays-for-parent
@ 2014-04-28 12:02 Peter Todd
  0 siblings, 0 replies; only message in thread
From: Peter Todd @ 2014-04-28 12:02 UTC (permalink / raw)
  To: bitcoin-development

[-- 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 --]

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2014-04-28 12:02 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-04-28 12:02 [Bitcoin-development] Replace-by-fee scorched-earth without child-pays-for-parent Peter Todd

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox