path: root/97/165a5b1ffa1004a723d16bbbcd984380a987a6

Return-Path: <jimmyjack@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id E3660308
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Aug 2016 16:29:32 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f172.google.com (mail-qt0-f172.google.com
	[209.85.216.172])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B408884
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Aug 2016 16:29:30 +0000 (UTC)
Received: by mail-qt0-f172.google.com with SMTP id w38so10006315qtb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Aug 2016 09:29:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to; 
	bh=PDeczQJUYWJ0biDmKGgshnMECCWKy7l87Gtl5nmMJrE=;
	b=VuLSmJi35BgW86cpn99Uv/fczvSsBpjNO0K0iOuOzGzDVhElL/1gT72h/8Xag03Yb/
	W6/aEeZL1IIIhbEL6GofubDGgwtTgkI2irYktWaT9qVj8B3yzZgP4fqaS1ZJg3JI5OtA
	BhIWbB+PsnNu+2yH4fmTVCv8cklbhcDifgGk0kETiKTmZ3qBHIvxzRlMO8vc5j1UPdLJ
	MkaLYpDxIE4bFBww5KLtGbd20I6YACcaS/OZSmHFF1Tr5aCxj6WAwkh4Uw8OmXmreU3y
	F1ajd2jRAXK+772AK2JjL3cIlyh5SCO/CirXWjc30JmBwN+9OL5dz8mtuWH+eN75DVx7
	tMZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to;
	bh=PDeczQJUYWJ0biDmKGgshnMECCWKy7l87Gtl5nmMJrE=;
	b=hKPvdQnooiC3MOoLbtbz92IYqt5CDJym4nbc3OOoG/wRTCuN4Bde6XsrSMUhlk4Ove
	pcgukFG5a/muT/AnsY508iniuGO5PWlJK/5ByKyaoJyLr69HAhjN2UAVCqWAjJaUQYKj
	k0VNALg5/QvV3P4hQ01jcF1j4b3FJmwwKsA70xwRbzZk0jtw5KZAYfdejJQ4YLTrsTHn
	+B6n2PF067h2nopsNQqMHyIi930WzBx8TWrXZjM4xyb80AuRdtaw/0f5+synjlGISOrM
	CO9Bs3+g/0VCJec1AWa263lQZPKr1fjuLc9r+eiwqsJNcvxRMB13ju+FKcwtPw7HUEEL
	L0UQ==
X-Gm-Message-State: AE9vXwMQqXwpHrS74d4sTr5UwKf5QMOtZXynYGuKdixNW+rTzA/l5cpq4Y5aTJxoTxlwaoDpe7v1glmrNlf17A==
X-Received: by 10.237.50.35 with SMTP id y32mr4547150qtd.98.1472056169938;
	Wed, 24 Aug 2016 09:29:29 -0700 (PDT)
MIME-Version: 1.0
References: <20160824014634.GA19905@fedora-21-dvm>
	<CAAEDBiEkGtj0HSBVgM1KGfsoLmpwK7QxGCTQE1z7FaCPtG2V6g@mail.gmail.com>
In-Reply-To: <CAAEDBiEkGtj0HSBVgM1KGfsoLmpwK7QxGCTQE1z7FaCPtG2V6g@mail.gmail.com>
From: Jimmy <jimmyjack@gmail.com>
Date: Wed, 24 Aug 2016 16:29:19 +0000
Message-ID: <CAE0GdZW-vN-kpUMATjkRQYnKH4n41HGdwQGb-JKZjcjxr6mO9g@mail.gmail.com>
To: Matthew Roberts <matthew@roberts.pm>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=94eb2c116a7a19445e053ad3c940
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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 16:32:28 +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 16:29:33 -0000

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

Is this unrelated to Bitcoin Vigil idea published in 2014?

http://www.coindesk.com/bitcoin-vigil-program-guards-against-intrusion-coin-theft/





On Wed, Aug 24, 2016 at 8:42 AM Matthew Roberts via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> 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 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
>>
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">Is this unrelated to Bitcoin Vigil idea published in 2014?=
<div><br></div><div><a href=3D"http://www.coindesk.com/bitcoin-vigil-progra=
m-guards-against-intrusion-coin-theft/">http://www.coindesk.com/bitcoin-vig=
il-program-guards-against-intrusion-coin-theft/</a><div><br></div><div><br>=
<div><br><div><br></div></div></div></div></div><br><div class=3D"gmail_quo=
te"><div dir=3D"ltr">On Wed, Aug 24, 2016 at 8:42 AM Matthew Roberts via bi=
tcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitc=
oin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">Really nice idea. So its like a smart contra=
ct that incentivizes publication that a server has been hacked? I also real=
ly like how the funding has been handled -- with all the coins stored in th=
e same address and then each server associated with a unique signature. Tha=
t way, you don&#39;t have to split up all the coins among every server and =
reduce the incentive for an attacker yet you can still identify which serve=
r was hacked.<br><br>It would be nice if after the attacker broke into the =
server that they were also incentivized to act on the information as soon a=
s 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&#39;re =
incentivzed to act lest their reward decays even more (this is of course, a=
ssuming that the monetary reward for this is greater than any possible lega=
l consequences for the attacker -- it might not be. Thinking about this som=
e more: it would also be somewhat hard to deny that this -wasn&#39;t- a hon=
eypot with such a complex and unique scheme required for transactions, and =
I for one wouldn&#39;t like to reveal that I&#39;d hacked a server if I kne=
w it was all a calculated ploy. Don&#39;t honeypots rely on subtly?)<br><br=
>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 o=
f compromise so incentivizing a security audit would kind of fall more into=
 an active invitation to audit but couldn&#39;t you also make a cryptocurre=
ncy 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 servi=
ce that broadcasts their public key hash, and then spend coins locked at th=
is special contract address to that pub key hash which miners would check o=
n redemption (putting aside malicious use-cases for now.)<br><br></div><div=
 class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Aug 24, 2016 =
at 11:46 AM, Peter Todd via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@l=
ists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_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/08/24/treesignatur=
es/</a><br>
<span><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>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--94eb2c116a7a19445e053ad3c940--