From: Gregory Maxwell <gmaxwell@gmail•com>
To: Pieter Wuille <pieter.wuille@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Double Spend Notification
Date: Mon, 20 May 2013 20:54:25 -0700 [thread overview]
Message-ID: <CAAS2fgRCpXUgw=GpE9_AcTgWcdCaDC6_16Xp5+oOZC0_1xmf-w@mail.gmail.com> (raw)
In-Reply-To: <CAPg+sBjmXyLkgfwzC8h+ZFkmyUf6nzbGo0oAWR9nsJOTOfOXEg@mail.gmail.com>
On Mon, May 20, 2013 at 6:56 PM, Pieter Wuille <pieter.wuille@gmail•com> wrote:
> On Tue, May 21, 2013 at 3:24 AM, Robert Backhaus <robbak@robbak•com> wrote:
>> So the decision has been made to make 0-conf double spends trivial, so no
>> one will ever trust 0-confs. If a later transaction appears with a larger
>> fee, it will be considered to be the valid one, and the first one dropped,
>> as long as the first one has not been confirmed. This makes undoing a
>> mistaken transaction possible.
> This has been suggested, but I know of no such decision having been made.
Indeed. I've argued against it pretty aggressively, but I am starting
to find arguments for and against pure fee-based replacement more
equally persuasive.
Regardless of the eventual outcome, fees today aren't a major
motivator vs subsidy and overall network health— and even if some
protection isn't 100% there are plenty of cases where the risk is
averaged across many small transactions and any reduction of risk is a
reduction in operating cost. (No one is going to double spend your
soda machine at high speed— so you can like increase your prices by
the amount of successful double spends you experience and call it
done)
On the other hand, it's well established that people underestimate the
costs of unlikely risks. More deterministic behavior can result in
safer interactions more than _better_ behavior. If we believe that in
the long term self-interest will result in pure-fee based replacement
being wide spread then it is also good to not build a dependency on
behavior that will not last.
One point that was only recently exposed to me is that replacement
combined with child-pays-for-parent creates a new kind of double spend
_defense_: If someone double spends a payment to an online key of
yours, you can instantly produce a child transaction that pays 100% of
the double spend to fees... so a double spender can hurt you but not
profit from it. (and if your side of the transaction is
potentially/partially reversible he will lose)...
But then again, a race to burn more money is kinda ... odd and even if
the benefit of resisting the double spends is only a short term
benefit, a short term benefit can be greatly important in encouraging
Bitcoin adoption. ... and the long term behavior is far from certain.
So at least from my position it's far from clear what should be done here.
I've noticed a number of people who seem to be swayed by replace by
fee— or at least its inevitability if not value. So even ignoring
developers there may evolve a community consensus here regardless of
what I think about it.
My SO pointed that that the transaction burning race described above
sounds like an economists wet dream: it's one of those silly cases
they use in experiments to probe human behavior... except it sounds
like a possible eventual outcome in systems used by people. Perhaps
it would be useful to point some graduate students at this question
and see what they can come up with about it.
next prev parent reply other threads:[~2013-05-21 3:54 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-21 0:45 Quinn Harris
2013-05-21 1:24 ` Robert Backhaus
2013-05-21 1:56 ` Pieter Wuille
2013-05-21 3:27 ` Mike Hearn
2013-05-21 3:39 ` Robert Backhaus
2013-05-21 13:06 ` Peter Todd
2013-05-21 3:54 ` Gregory Maxwell [this message]
2013-05-21 4:39 ` Gavin Andresen
2013-05-21 7:04 ` Gregory Maxwell
2013-05-21 8:08 ` Robert Backhaus
2013-05-21 13:05 ` Peter Todd
2013-05-21 14:26 ` David Vorick
2013-05-21 16:47 ` Quinn Harris
2013-05-21 3:46 ` Quinn Harris
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='CAAS2fgRCpXUgw=GpE9_AcTgWcdCaDC6_16Xp5+oOZC0_1xmf-w@mail.gmail.com' \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pieter.wuille@gmail$(echo .)com \
/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