From: Chris Priest <cp368202@ohiou•edu>
To: Peter Todd <pete@petertodd•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection
Date: Wed, 24 Aug 2016 16:03:16 -0700 [thread overview]
Message-ID: <CAAcC9yvh_BSerOeGka=9T_wOkUDw6bMGj=MWoBP4N16EswcKcw@mail.gmail.com> (raw)
In-Reply-To: <20160824192211.GB24668@fedora-21-dvm>
How does your system prevent against insider attacks? How do you know
the money is stolen by someone who compromised server #4, and not
stolen by the person who set up server #4? It is my understanding
these days most attacks are inside jobs.
On 8/24/16, Peter Todd via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Thu, Aug 25, 2016 at 01:37:34AM +1000, Matthew Roberts wrote:
>> Really nice idea. So its like a smart contract that incentivizes
>> publication that a server has been hacked? I also really like how the
>> funding has been handled -- with all the coins stored in the same address
>> and then each server associated with a unique signature. That way, you
>> don't have to split up all the coins among every server and reduce the
>> incentive for an attacker yet you can still identify which server was
>> hacked.
>>
>> It would be nice if after the attacker broke into the server that they
>> were
>> also incentivized to act on the information as soon as possible
>> (revealing
>> early on when the server was compromised.) I suppose you could split up
>> the
>> coins into different outputs that could optimally be redeemed by the
>> owner
>> at different points in the future -- so they're incentivzed to act lest
>
> Remember that it's _always_ possible for the owner to redeem the coins at
> any
> time, and there's no way to prevent that.
>
> The incentive for the intruder to collect the honeypot in a timely manner
> is
> simple: once they've broken in, the moment the honeypot owner learns about
> the
> compromise they have every reason to attempt to recover the funds, so the
> intruder needs to act as fast as possible to maximize their chances of
> being
> rewarded.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
next prev parent reply other threads:[~2016-08-24 23:03 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 [this message]
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
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='CAAcC9yvh_BSerOeGka=9T_wOkUDw6bMGj=MWoBP4N16EswcKcw@mail.gmail.com' \
--to=cp368202@ohiou$(echo .)edu \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--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