[bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection

[bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 5396 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection

[Matthew Roberts]

[-- Attachment #1: Type: text/plain, Size: 7788 bytes --]

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
>
>

[-- Attachment #2: Type: text/html, Size: 8988 bytes --]

Re: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection

[Jimmy]

[-- Attachment #1: Type: text/plain, Size: 8474 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 10039 bytes --]

Re: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 524 bytes --]

On Wed, Aug 24, 2016 at 04:29:19PM +0000, Jimmy wrote:
> Is this unrelated to Bitcoin Vigil idea published in 2014?
> 
> http://www.coindesk.com/bitcoin-vigil-program-guards-against-intrusion-coin-theft/

I think it's very related; to be absolutely clear the idea of a Bitcoin
honeypot is 100% not my idea! Also, if anyone else had previously invented the
techniques I (and Jeff Coleman) invented, I'd love to hear about it so I can
give appropriate credit.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1414 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection

[Chris Priest]

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
>

Re: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection

[Gregory Maxwell]

On Wed, Aug 24, 2016 at 11:03 PM, Chris Priest via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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.

Working as designed in that case:  You know #4 is compromised, it
doesn't tell you if it was an insider or an outsider, but in both
cases someone unauthorized or without integrity got access to the
key(s).

Re: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection

[James MacWhyte]

[-- Attachment #1: Type: text/plain, Size: 6459 bytes --]

I've always assumed honeypots were meant to look like regular, yet
poorly-secured, assets. If the intruder could identify this as a honeypot
by the strange setup (presigned, non-standard transactions lying around)
and was aware that the creator intended to doublespend as soon as the
transaction was discovered, wouldn't they instead prefer to not touch
anything and wait for a non-bait target to appear? Is the assumption here
that the intruder wouldn't know this is a honeypot, or that they would know
and it's just assumed that they would rather take their chances on this
instead of causing some other trouble?

On Tue, Aug 23, 2016 at 6:47 PM 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
>

[-- Attachment #2: Type: text/html, Size: 7509 bytes --]

Re: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection

[Christian Decker]

On Thu, Aug 25, 2016 at 02:54:47AM +0000, James MacWhyte via bitcoin-dev wrote:
> I've always assumed honeypots were meant to look like regular, yet
> poorly-secured, assets. If the intruder could identify this as a honeypot
> by the strange setup (presigned, non-standard transactions lying around)
> and was aware that the creator intended to doublespend as soon as the
> transaction was discovered, wouldn't they instead prefer to not touch
> anything and wait for a non-bait target to appear? Is the assumption here
> that the intruder wouldn't know this is a honeypot, or that they would know
> and it's just assumed that they would rather take their chances on this
> instead of causing some other trouble?

That strongly depends on the value of the compromised machine to the
attacker. If he has syphoned all the data from it and has no further
use for it then the he will probably trip the tripwire to get the
coins even though this will make the compromise apparent. If however
he is planning to use it as a foothold to further compromise your
company, send spam or similar, he will likely try to avoid these
tripwires. In which case a classic honeypot, that attempts to look
like a regular system is what you're looking for.

Re: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection

[Gregory Maxwell]

On Thu, Aug 25, 2016 at 2:27 PM, Christian Decker via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> If however
> he is planning to use it as a foothold to further compromise your
> company, send spam or similar, he will likely try to avoid these
> tripwires. [...]

Depends on the value of their activity compared to the value of the coins.
Spamming doesn't pay much.

Covert tripwires would obviously be better, but if shared tripwires
allow you to have 100x the funds available it could be a good
trade-off.

Re: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection

[James MacWhyte]

[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]

Why not just have a single 1-of-m multisig transaction, with one key on
each server? Based on which key is used you would know which server is
compromised, and (in my opinion) it wouldn't look nearly as suspicious.

On Thu, Aug 25, 2016 at 11:26 AM Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thu, Aug 25, 2016 at 2:27 PM, Christian Decker via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > If however
> > he is planning to use it as a foothold to further compromise your
> > company, send spam or similar, he will likely try to avoid these
> > tripwires. [...]
>
> Depends on the value of their activity compared to the value of the coins.
> Spamming doesn't pay much.
>
> Covert tripwires would obviously be better, but if shared tripwires
> allow you to have 100x the funds available it could be a good
> trade-off.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 1658 bytes --]

Re: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection

[Peter Todd]

On 25 August 2016 14:26:21 GMT-04:00, Gregory Maxwell via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>On Thu, Aug 25, 2016 at 2:27 PM, Christian Decker via bitcoin-dev
><bitcoin-dev@lists.linuxfoundation.org> wrote:
>> If however
>> he is planning to use it as a foothold to further compromise your
>> company, send spam or similar, he will likely try to avoid these
>> tripwires. [...]
>
>Depends on the value of their activity compared to the value of the
>coins.
>Spamming doesn't pay much.
>
>Covert tripwires would obviously be better, but if shared tripwires
>allow you to have 100x the funds available it could be a good
>trade-off.

Also, having a overt tripwire doesn't preclude having covert tripwires as well.


In any case, this all deserves a Standard™ to make sure intruders know where to look to find the funds. Maybe /var/honeypot...

Re: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection

[Peter Todd]

On 24 August 2016 22:54:47 GMT-04:00, James MacWhyte <macwhyte@gmail.com> wrote:
>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.

> If the intruder could identify this as a
>honeypot
>by the strange setup (presigned, non-standard transactions lying
>around)
>and was aware that the creator intended to doublespend as soon as the
>transaction was discovered, wouldn't they instead prefer to not touch
>anything and wait for a non-bait target to appear?

Re-read my last section on the "scorched earth" disincentive to doublespend the intruder.

Re: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection

[James MacWhyte]

[-- 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 --]

Re: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1879 bytes --]

On Wed, Aug 31, 2016 at 07:48:50PM +0000, James MacWhyte wrote:
> >
> > >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.

Ah, yeah, I think you have a point re: naming - this isn't quite the
traditional honeypot, as we uniquely have the ability to give the attackers a
reward in a way where it's ok for the intruder to know that they've been
detected; with traditional non-monetary honeypots it's quite difficult to come
up with a scenario where it's ok for an intruder to gain something from the
intrusion, so you're forced to use deception instead.

Perhaps a better term for this technique would be a "compromise canary"? Or
"intruder bait"? After all, in wildlife animal research it's common to use bait
as a way of attracting targets to discover that they exist (e.g. w/ wildlife
cameras), even when you have no intention of doing any harm to the animal.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]