From: Quinn Harris <btcdev@quinnharris.me>
To: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Double Spend Notification
Date: Tue, 21 May 2013 10:47:59 -0600 [thread overview]
Message-ID: <519BA53F.7090404@quinnharris.me> (raw)
In-Reply-To: <20130521130534.GA27580@tilt>
What if a transaction is tagged as eligible for replace by fee possibly
using the lock_time (0xFFFFFFFE) so the parties involved can decide
which approach works best for them. If the receiving side doesn't see
the type of transaction they want they consider it invalid. The payment
protocol can be used to negotiate which method should be used.
If lock_time is final as it is now for all standard transactions, the
current behaviour for transaction propagation would be kept with the
addition of double spend proof notifications as I described. But if the
transactions are tagged appropriately, they would be replaced by fee.
In the recommended implementation, once a node sees a transaction that
is not eligible to be replaced by fee it would treat all successive
transactions that way despite the tag.
This shouldn't hurt merchants that wish to use just double spend
notification while still enabling replace by fee for those who think it
is preferred.
I do find the burn coins and buyer pays twice with a merchant refund to
be compelling solutions, but you can't always trust the merchant (face
to face street merchant). Also, there is a short window of time were a
block can be mined before the burn coin counter measure is received. It
is isn't guaranteed this will work better than current behaviour with
double spend notification especially considering notification don't cost
the merchant when it works.
- Quinn
next prev parent reply other threads:[~2013-05-21 16:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-21 0:45 [Bitcoin-development] Double Spend Notification 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
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 [this message]
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=519BA53F.7090404@quinnharris.me \
--to=btcdev@quinnharris.me \
--cc=bitcoin-development@lists.sourceforge.net \
/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