From: Isidor Zeuner <cryptocurrencies@quidecco•de>
To: Paul Goldstein <paul@realfoot•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension
Date: Tue, 17 Jun 2014 17:58:45 +0200 (CEST) [thread overview]
Message-ID: <20140617155845.8177ADFC55C@quidecco.de> (raw)
In-Reply-To: <CADE3-jA8LizD8cjdqKm0pFc8OV7JqPBGhs4uvp6=VhEU2emV6w@mail.gmail.com>
quote:
> Mike Hearn, why don't we just have all nodes report attempted double spends
> through the node network. No need to involve the miners at all really, or
> do your suggestion but also report the double spend attempt. By waiting
> maybe 10-60 seconds (instead of 10 minutes for first conf), merchants can
> be more sure that a double spend attack was not tried. Attacker would have
> to hold back second tx by 10-60 seconds and hope that that second tx (with
> higher fee) get's into a solved block before the first one. This forced
> delay time ought to make the attack less successful (but not impossible).
>
What prevents the following steps from happening:
1. attacker sends first transaction, paying to the merchant
2. merchant waits 10-60 seconds
3. merchant confirms the payment as received
4. attacker sees merchant's confirmation
5. attacker sends double spend
The security improvement seems to be pretty much exactly the chance
that during the 10-60 seconds, a block is solved. Am I missing
something?
Regarding "reporting double spends", this would only help if it comes
with some kind of penalty for the double spend. Now what if the double
spend was not done on malicious motives? Maybe someone posted a
transaction which does not confirm for some reason, and wants to
recover his funds? Should we regard transactions which do not confirm
as forever lost, in order to get to an "every double spend is a
misbehaviour" policy?
Best regards,
Isidor
next prev parent reply other threads:[~2014-06-17 15:58 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-14 12:00 Lawrence Nahum
2014-06-14 12:57 ` Andreas Schildbach
2014-06-15 9:22 ` Lawrence Nahum
2014-06-15 12:46 ` Andreas Schildbach
2014-06-15 14:09 ` Lawrence Nahum
2014-06-18 12:09 ` Lawrence Nahum
2014-06-18 13:25 ` Mike Hearn
2014-06-18 15:59 ` Daniel Rice
2014-06-18 16:09 ` Mike Hearn
2014-06-19 17:36 ` Daniel Rice
2014-06-25 14:01 ` sebastien requiem
2014-06-16 12:19 ` Mike Hearn
2014-06-16 12:25 ` Mike Hearn
2014-06-16 15:09 ` Daniel Rice
2014-06-16 15:26 ` Lawrence Nahum
2014-06-16 16:00 ` Daniel Rice
2014-06-16 16:07 ` Mike Hearn
2014-06-16 15:41 ` Paul Goldstein
2014-06-16 15:48 ` Mike Hearn
2014-06-16 16:30 ` Lawrence Nahum
2014-06-16 16:45 ` Mike Hearn
2014-06-16 16:56 ` Lawrence Nahum
2014-06-16 17:01 ` Mike Hearn
2014-06-16 17:16 ` Lawrence Nahum
2014-06-16 18:02 ` Alex Kotenko
2014-06-16 18:09 ` Mike Hearn
2014-06-16 20:29 ` Daniel Rice
2014-06-16 20:32 ` Mike Hearn
2014-06-16 20:37 ` Daniel Rice
2014-06-16 20:46 ` Mike Hearn
2014-06-16 20:53 ` Daniel Rice
2014-06-16 20:55 ` Mike Hearn
2014-06-16 20:50 ` [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees Peter Todd
2014-06-16 21:02 ` [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension Daniel Rice
2014-06-16 20:32 ` Alex Kotenko
2014-06-16 17:44 ` Jorge Timón
2014-06-17 15:58 ` Isidor Zeuner
2014-06-18 1:39 ` Tom Harding
2014-06-17 15:58 ` Isidor Zeuner [this message]
2014-06-18 9:15 ` Mike Hearn
2014-06-18 20:47 ` Natanael
2014-06-18 2:01 ` Tom Harding
2014-06-16 15:28 ` Lawrence Nahum
2014-06-16 15:43 ` Mike Hearn
2014-06-16 17:05 ` Lawrence Nahum
2014-06-16 8:53 Daniel Rice
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=20140617155845.8177ADFC55C@quidecco.de \
--to=cryptocurrencies@quidecco$(echo .)de \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=paul@realfoot$(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