path: root/54/c0bc3f2d4b5121361767472cad3fdb76324f32

Return-Path: <matthew@roberts.pm>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id A49BB305
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Aug 2016 15:37:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it0-f54.google.com (mail-it0-f54.google.com
	[209.85.214.54])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 115421EA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Aug 2016 15:37:36 +0000 (UTC)
Received: by mail-it0-f54.google.com with SMTP id n128so40537687ith.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Aug 2016 08:37:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=roberts-pm.20150623.gappssmtp.com; s=20150623;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=rSgzqohm4B9Ewk29Fs5p+yWaV/GhgJ1Phg/kISeUqLc=;
	b=kpJeslTjBKbu+MMvmBm3C/uAHJYt1RGSjV0mlUEzn774Y1UuhDoAX2UsecLy2cY5cX
	d2UImbLrZw4j/WHwp8OzOJBFMhykCab3kwnCcLyAXM6BzClIq8ikTZySOsJ7Y21dU3iP
	3OtFv8pt2wiOoLbDW8139lQ1F2MVHGplds9WdgPhcYXhts9BYUjTNyw29Gme1rYOJEtp
	reYQl8fcLN8WtjN+u1thRFXUNjhMYmxzZMHcmmhbdM86hsRyeLjsC8eQyMcbk/PCMsXP
	5EGDX38jW7+QvfVdeareiTfmvFFy2dwmWLjkSWdWPrxAeTEeN0lnq0qeB0uWLw+lXcgI
	s/pA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=rSgzqohm4B9Ewk29Fs5p+yWaV/GhgJ1Phg/kISeUqLc=;
	b=DI1p//Bt3IE210XEhAcVq5hWyyCxshVpmpDu9bQuVuap/RGxb4pdpqZ/W8i1HCBK0B
	zwWrAxGov4RqENEupFlrs/SYJhzRD74Rd3kKuMHNnDQM0i7Azw21aByz4b0Z/FXcEB+g
	tRB1p3+a9j2GuqWmaZrc9e4yFeymAoFgvAoIC1uaeR4p3wELR1ldg4uKIzIpJPXiBOco
	JDT7oqxV847ysJN+SYAAwL6AGjaqczz1camrKjX3zv9Ab/yPJp2Lpb/wOv5Cz+JGtUFe
	BKnem8pbJg3r0Ixi+y+BSz+ZvnGmrQrnOn76oSMDjEgAyf0v3gegoHPEvYf7QmcU0UP4
	ocIQ==
X-Gm-Message-State: AE9vXwM4GdyZ3Z++BRF6ea0z0p7/1/4SGMTqtsLVJERY6KYNwlAhL+GdThJqNQM0kRW1o8gnoXm1AxZ/p2czGQ==
X-Received: by 10.107.23.66 with SMTP id 63mr5373265iox.169.1472053055219;
	Wed, 24 Aug 2016 08:37:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.57.69 with HTTP; Wed, 24 Aug 2016 08:37:34 -0700 (PDT)
X-Originating-IP: [115.70.56.56]
In-Reply-To: <20160824014634.GA19905@fedora-21-dvm>
References: <20160824014634.GA19905@fedora-21-dvm>
From: Matthew Roberts <matthew@roberts.pm>
Date: Thu, 25 Aug 2016 01:37:34 +1000
Message-ID: <CAAEDBiEkGtj0HSBVgM1KGfsoLmpwK7QxGCTQE1z7FaCPtG2V6g@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c05c23e72d2d0053ad30f73
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 24 Aug 2016 15:41:13 +0000
Subject: Re: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth"
 Doublespending Protection
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Aug 2016 15:37:37 -0000

--94eb2c05c23e72d2d0053ad30f73
Content-Type: text/plain; charset=UTF-8

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
their reward decays even more (this is of course, assuming that the
monetary reward for this is greater than any possible legal consequences
for the attacker -- it might not be. Thinking about this some more: it
would also be somewhat hard to deny that this -wasn't- a honeypot with such
a complex and unique scheme required for transactions, and I for one
wouldn't like to reveal that I'd hacked a server if I knew it was all a
calculated ploy. Don't honeypots rely on subtly?)

What about also proving to an attacker that by breaking into a server they
would be guaranteed a reward? I know that the use-case for this is proof of
compromise so incentivizing a security audit would kind of fall more into
an active invitation to audit but couldn't you also make a cryptocurrency
that allowed coins to be moved based on a service banner existing at a
given IP address? Attackers could then break into the server, setup a
service that broadcasts their public key hash, and then spend coins locked
at this special contract address to that pub key hash which miners would
check on redemption (putting aside malicious use-cases for now.)


On Wed, Aug 24, 2016 at 11:46 AM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Bitcoin-based honeypots incentivise intruders into revealing the fact they
> have
> broken into a server by allowing them to claim a reward based on secret
> information obtained during the intrusion. Spending a bitcoin can only be
> done
> by publishing data to a public place - the Bitcoin blockchain - allowing
> detection of the intrusion.
>
> The simplest way to achieve this is with one private key per server, with
> each
> server associated with one transaction output spendable by that key.
> However
> this isn't capital efficient if you have multiple servers to protect: if we
> have N servers and P bitcoins that we can afford to lose in the
> compromise, one
> key per server gives the intruder only N/P incentive.
>
> Previously Piete Wuille proposed(1) tree signatures for honeypots, with a
> single txout protected by a 1-N tree of keys, with each server assigned a
> specific key. Unfortunately though, tree signatures aren't yet implemented
> in
> the Bitcoin protocol.
>
> However with a 2-of-2 multisig and the SIGHASH_SINGLE feature we can
> implement
> this functionality with the existing Bitcoin protocol using the following
> script:
>
>     2 <honeypot-pubkey> <distriminator-pubkey> 2 CHECKMULTISIG
>
> The honeypot secret key is shared among all N servers, and left on them.
> The
> distriminator secret key meanwhile is kept secret, however for each server
> a
> unique signature is created with SIGHASH_SINGLE, paying a token amount to a
> notification address. For each individual server a pre-signed signature
> created
> with the distriminator secret key is then left on the associated server
> along
> with the honeypot secret key.
>
> Recall the SIGHASH_SINGLE flag means that the signature only signs a single
> transaction input and transaction output; the transaction is allowed to
> have
> additional inputs and outputs added. This allows the thief to use the
> honeypot
> key to construct a claim transaction with an additional output added that
> pays
> an address that they own with the rest of the funds.
>
> Equally, we could also use SIGHASH_NONE, with the per-server discriminator
> being the K value used in the pre-signed transaction.
>
> Note that Jeff Coleman deserves credit as co-inventor of all the above.
>
>
> Censorship Resistance
> =====================
>
> A potential disadvantage of using non-standard SIGHASH flags is that the
> transactions involved are somewhat unusual, and may be flagged by
> risk analysis at exchanges and the like, a threat to the fungibility of the
> reward.
>
> We can improve on the above concept from Todd/Coleman by using a pre-signed
> standard transaction instead. The pre-signed transaction spends the
> honeypot
> txout to two addresses, a per-server canary address, and a change address.
> The
> private key associated with the change addres is also left on the server,
> and
> the intruder can then spend that change output to finally collect their
> reward.
>
> To any external observer the result looks like two normal transactions
> created
> in the process of someone with a standard wallet sending a small amount of
> funds to an address, followed by sending a larger amount.
>
>
> Doublespending
> ==============
>
> A subtlety in the the two transactions concept is that the intruder doesn't
> have the necessary private keys to modify the first transaction, which
> means
> that the honeypot owner can respond to the compromise by doublespending
> that
> transaction, potentially recovering the honeypot while still learning
> about the
> compromise. While this is possible with all honeypots, if the first
> transaction
> is signed with the opt-in RBF flags, and CPFP-aware transaction
> replacement is
> not implemented by miners, the mechanics are particularly disadvantageous
> to
> the intruder, as the honeypot owner only needs to increase the first
> transaction's fee slightly to have a high chance of recovering their funds.
> With CPFP-aware transaction replacement the intruder could in-turn respond
> with
> a high-fee CPFP second transaction, but currently no such implementation is
> known.
>
>
> Scorched Earth
> ==============
>
> We can use the "scorched earth" concept to improve the credibility of the
> honeypot reward by making it costly for the honeypot owner to doublespend.
> Here
> a second version of the honeypot pre-signed transaction would also be
> provided
> which sepnds the entirety of the honeypot output to fees, and additionally
> spends a second output to fees. An economically rational intruder will
> publish
> the first version, which maximizes the funds they get out of the honeypot.
> If
> the owner tries to dishonestly doublespend, they can respond by publishing
> the
> "scorched earth" transaction, encouraging the honeypot owner's honesty and
> making CPFP-aware transaction replacement irrelevant.
>
> Of course, miner centralization adds complexity to the above: in many
> instances
> honeypot owners and/or intruders will be able to recover funds from
> altruistic
> miners. Equally, the additional complexity may discourage intruders from
> making
> use of the honeypot entirely.
>
> Note that as an implementation consideration CHECKSEQUENCEVERIFY can be
> used to
> ensure the honeypot output can only be spent with transaction replacement
> enabled, as CSV requires nSequence to be set in specific ways in any
> transation
> spending the output.
>
>
> References
> ==========
>
> 1) https://blockstream.com/2015/08/24/treesignatures/
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--94eb2c05c23e72d2d0053ad30f73
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Really nice idea. So its like a smart contract that incent=
ivizes publication that a server has been hacked? I also really like how th=
e 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=
&#39;t have to split up all the coins among every server and reduce the inc=
entive for an attacker yet you can still identify which server was hacked.<=
br><br>It would be nice if after the attacker broke into the server that th=
ey were also incentivized to act on the information as soon as possible (re=
vealing early on when the server was compromised.) I suppose you could spli=
t up the coins into different outputs that could optimally be redeemed by t=
he owner at different points in the future -- so they&#39;re incentivzed to=
 act lest their reward decays even more (this is of course, assuming that t=
he monetary reward for this is greater than any possible legal consequences=
 for the attacker -- it might not be. Thinking about this some more: it wou=
ld also be somewhat hard to deny that this -wasn&#39;t- a honeypot with suc=
h a complex and unique scheme required for transactions, and I for one woul=
dn&#39;t like to reveal that I&#39;d hacked a server if I knew it was all a=
 calculated ploy. Don&#39;t honeypots rely on subtly?)<br><br>What about al=
so proving to an attacker that by breaking into a server they would be guar=
anteed a reward? I know that the use-case for this is proof of compromise s=
o incentivizing a security audit would kind of fall more into an active inv=
itation to audit but couldn&#39;t you also make a cryptocurrency that allow=
ed coins to be moved based on a service banner existing at a given IP addre=
ss? Attackers could then break into the server, setup a service that broadc=
asts their public key hash, and then spend coins locked at this special con=
tract address to that pub key hash which miners would check on redemption (=
putting aside malicious use-cases for now.)<br><br></div><div class=3D"gmai=
l_extra"><br><div class=3D"gmail_quote">On Wed, Aug 24, 2016 at 11:46 AM, P=
eter Todd via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-d=
ev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoun=
dation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Bitcoin-=
based honeypots incentivise intruders into revealing the fact they have<br>
broken into a server by allowing them to claim a reward based on secret<br>
information obtained during the intrusion. Spending a bitcoin can only be d=
one<br>
by publishing data to a public place - the Bitcoin blockchain - allowing<br=
>
detection of the intrusion.<br>
<br>
The simplest way to achieve this is with one private key per server, with e=
ach<br>
server associated with one transaction output spendable by that key. Howeve=
r<br>
this isn&#39;t capital efficient if you have multiple servers to protect: i=
f we<br>
have N servers and P bitcoins that we can afford to lose in the compromise,=
 one<br>
key per server gives the intruder only N/P incentive.<br>
<br>
Previously Piete Wuille proposed(1) tree signatures for honeypots, with a<b=
r>
single txout protected by a 1-N tree of keys, with each server assigned a<b=
r>
specific key. Unfortunately though, tree signatures aren&#39;t yet implemen=
ted in<br>
the Bitcoin protocol.<br>
<br>
However with a 2-of-2 multisig and the SIGHASH_SINGLE feature we can implem=
ent<br>
this functionality with the existing Bitcoin protocol using the following<b=
r>
script:<br>
<br>
=C2=A0 =C2=A0 2 &lt;honeypot-pubkey&gt; &lt;distriminator-pubkey&gt; 2 CHEC=
KMULTISIG<br>
<br>
The honeypot secret key is shared among all N servers, and left on them. Th=
e<br>
distriminator secret key meanwhile is kept secret, however for each server =
a<br>
unique signature is created with SIGHASH_SINGLE, paying a token amount to a=
<br>
notification address. For each individual server a pre-signed signature cre=
ated<br>
with the distriminator secret key is then left on the associated server alo=
ng<br>
with the honeypot secret key.<br>
<br>
Recall the SIGHASH_SINGLE flag means that the signature only signs a single=
<br>
transaction input and transaction output; the transaction is allowed to hav=
e<br>
additional inputs and outputs added. This allows the thief to use the honey=
pot<br>
key to construct a claim transaction with an additional output added that p=
ays<br>
an address that they own with the rest of the funds.<br>
<br>
Equally, we could also use SIGHASH_NONE, with the per-server discriminator<=
br>
being the K value used in the pre-signed transaction.<br>
<br>
Note that Jeff Coleman deserves credit as co-inventor of all the above.<br>
<br>
<br>
Censorship Resistance<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
A potential disadvantage of using non-standard SIGHASH flags is that the<br=
>
transactions involved are somewhat unusual, and may be flagged by<br>
risk analysis at exchanges and the like, a threat to the fungibility of the=
<br>
reward.<br>
<br>
We can improve on the above concept from Todd/Coleman by using a pre-signed=
<br>
standard transaction instead. The pre-signed transaction spends the honeypo=
t<br>
txout to two addresses, a per-server canary address, and a change address. =
The<br>
private key associated with the change addres is also left on the server, a=
nd<br>
the intruder can then spend that change output to finally collect their rew=
ard.<br>
<br>
To any external observer the result looks like two normal transactions crea=
ted<br>
in the process of someone with a standard wallet sending a small amount of<=
br>
funds to an address, followed by sending a larger amount.<br>
<br>
<br>
Doublespending<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
A subtlety in the the two transactions concept is that the intruder doesn&#=
39;t<br>
have the necessary private keys to modify the first transaction, which mean=
s<br>
that the honeypot owner can respond to the compromise by doublespending tha=
t<br>
transaction, potentially recovering the honeypot while still learning about=
 the<br>
compromise. While this is possible with all honeypots, if the first transac=
tion<br>
is signed with the opt-in RBF flags, and CPFP-aware transaction replacement=
 is<br>
not implemented by miners, the mechanics are particularly disadvantageous t=
o<br>
the intruder, as the honeypot owner only needs to increase the first<br>
transaction&#39;s fee slightly to have a high chance of recovering their fu=
nds.<br>
With CPFP-aware transaction replacement the intruder could in-turn respond =
with<br>
a high-fee CPFP second transaction, but currently no such implementation is=
<br>
known.<br>
<br>
<br>
Scorched Earth<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
We can use the &quot;scorched earth&quot; concept to improve the credibilit=
y of the<br>
honeypot reward by making it costly for the honeypot owner to doublespend. =
Here<br>
a second version of the honeypot pre-signed transaction would also be provi=
ded<br>
which sepnds the entirety of the honeypot output to fees, and additionally<=
br>
spends a second output to fees. An economically rational intruder will publ=
ish<br>
the first version, which maximizes the funds they get out of the honeypot. =
If<br>
the owner tries to dishonestly doublespend, they can respond by publishing =
the<br>
&quot;scorched earth&quot; transaction, encouraging the honeypot owner&#39;=
s honesty and<br>
making CPFP-aware transaction replacement irrelevant.<br>
<br>
Of course, miner centralization adds complexity to the above: in many insta=
nces<br>
honeypot owners and/or intruders will be able to recover funds from altruis=
tic<br>
miners. Equally, the additional complexity may discourage intruders from ma=
king<br>
use of the honeypot entirely.<br>
<br>
Note that as an implementation consideration CHECKSEQUENCEVERIFY can be use=
d to<br>
ensure the honeypot output can only be spent with transaction replacement<b=
r>
enabled, as CSV requires nSequence to be set in specific ways in any transa=
tion<br>
spending the output.<br>
<br>
<br>
References<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
1) <a href=3D"https://blockstream.com/2015/08/24/treesignatures/" rel=3D"no=
referrer" target=3D"_blank">https://blockstream.com/2015/<wbr>08/24/treesig=
natures/</a><br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> &#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org"=
 rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
</font></span><br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>

--94eb2c05c23e72d2d0053ad30f73--