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 >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
