From: James MacWhyte <macwhyte@gmail•com>
To: Peter Todd <pete@petertodd•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Cc: Jeff Coleman <jeff@ledgerlabs•io>
Subject: Re: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection
Date: Wed, 31 Aug 2016 19:48:50 +0000 [thread overview]
Message-ID: <CAH+Axy6eOtqoLt5A40qYQG4S6UgFfEQeaM3Dgo677ZaH3NhQ5Q@mail.gmail.com> (raw)
In-Reply-To: <82507740-C4A3-4AF2-BA02-3B29E5FECDE4@petertodd.org>
[-- Attachment #1: Type: text/plain, Size: 1275 bytes --]
>
> >I've always assumed honeypots were meant to look like regular, yet
> >poorly-secured, assets.
>
> Not at all. Most servers have zero reason to have any Bitcoin's accessible
> via them, so the presence of BTC privkeys is a gigantic red flag that they
> are part of a honeypot.
>
I was talking about the traditional concept. From Wikipedia: "Generally, a
honeypot consists of data (for example, in a network site) that appears to
be a legitimate part of the site but is actually isolated and monitored,
and that seems to contain information or a resource of value to attackers,
which are then blocked."
I would argue there are ways to make it look like it is not a honeypot
(plenty of bitcoin services have had their hot wallets hacked before, and
if the intruder only gains access to one server they wouldn't know that all
the servers have the same honeypot on them). But I was just confirming that
the proposal is for an obvious honeypot.
> Re-read my last section on the "scorched earth" disincentive to
> doublespend the intruder.
>
> The first time I read it I didn't realize that the second transaction the
intruder has is designed to waste the honeypot AND additional funds
belonging to the honeypot creator. That's pretty good, from a game theory
perspective.
[-- Attachment #2: Type: text/html, Size: 1709 bytes --]
next prev parent reply other threads:[~2016-08-31 19:49 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-24 1:46 Peter Todd
2016-08-24 15:37 ` Matthew Roberts
2016-08-24 16:29 ` Jimmy
2016-08-24 19:18 ` Peter Todd
2016-08-24 19:22 ` Peter Todd
2016-08-24 23:03 ` Chris Priest
2016-08-24 23:38 ` Gregory Maxwell
2016-08-25 2:54 ` James MacWhyte
2016-08-25 14:27 ` Christian Decker
2016-08-25 18:26 ` Gregory Maxwell
2016-08-28 2:50 ` James MacWhyte
2016-08-28 4:42 ` Peter Todd
2016-08-28 4:37 ` Peter Todd
2016-08-31 19:48 ` James MacWhyte [this message]
2016-08-31 20:01 ` Peter Todd
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=CAH+Axy6eOtqoLt5A40qYQG4S6UgFfEQeaM3Dgo677ZaH3NhQ5Q@mail.gmail.com \
--to=macwhyte@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jeff@ledgerlabs$(echo .)io \
--cc=pete@petertodd$(echo .)org \
/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