From: Dr Maxim Orlovsky <orlovsky@protonmail•com>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Storm: escrowed storage and messaging at L2/L3
Date: Wed, 21 Aug 2019 17:04:35 +0000 [thread overview]
Message-ID: <yBkmyGw473TegSTQPwap9mH7xT4yHWeFBAuq7Whztr56CPIMeN4Ld0edRg9uGnvTGhUy_GML8pM9XHnIHPxBc4Cv0MVejhlclbC_6eMFsKI=@protonmail.com> (raw)
In-Reply-To: <x1b18QXzxALwxxp8ehwcB7XORizrw5vOJ9BNXWpXbd2SJgUra-AFIyTgnM_yxKEtCg_frZcz916NLmm-pTsCD4Z7aOFprdQ_W87mHnn8vYg=@protonmail.com>
Hi ZmnSCPxj,
> The Deaf Bob Attack
> =============================================
> - If Alice does not publish the HTLC settlement transaction, then Bob will eventually enter the N2 state and get the stake+reward.
> - If Alice does publish the HTLC settlement transaction, without Bob giving the encrypted data, then Bob can just use the hashlock and reveal the decryption key.
> - The decryption key is useless without the encrypted data!
That is the main attack already addressed by couple of other guys in different forms; and you have provided the most detailed explanation of it, thank you. I was working for its solution over the last day and I'd like to propose the following update: https://github.com/storm-org/storm-spec/issues/6#issuecomment-523497555
Briefly, I introduce two new intermediary HTLC transactions (called confirmation and fallbacks). Alice has now a choice to sign HTLC fallback tx if she didn't get the data, and in that case she will get her money (reward) back and Bob's stake as a compensation. Bob can "appeal" to this by confirming that he had hold the data for Alice. Bob does this by providing a "preimage" to the secret hashed by Alice.
This secret is composed at setup time by Alice, and she uses her newly-derived public key for both funding transaction output and deterministically definition of some small portion of the source data. This portion is double-hashed to 160-bit hash and included into HTLC fallback tx by Alice as a hash lock. Later, when Bob wants to prove that he still has the data available, he see the published HTLC transaction, extracts Alice public key and uses it to get the same deterministic piece of the source data as Alice. Bob computes a single hash on the date, which gives him a preimage to unlock the hash lock from HTLC transaction output before Alice will spend it (Alice's output is timelocked).
This solution requires Bob to select decription key at setup time, when he pre-signs the transaction, as you correctly have pointed out:
> If Bob already selected the decryption key at setup time, then Bob can ignore Alice.
Now, we need to aviod situation where by selecting the encryption/decryption pair Bob knows which part of the data he needs to provide Alice in PCP proof, and can discard the rest of the data. This can be mitigated by requiring that the data have to be encrypted using EC multiplication with some factor provided by Alice at the request time.
The only case for possible cheating now is Alice not needing data anymore and avoiding paying the full amount for the storage. However, this can be a part of the Bob business risk and may be covered by some insurance + Alice's reputation & taken into account by Bob at setup time.
Kind regards,
Maxim Orlovsky
next prev parent reply other threads:[~2019-08-21 17:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-19 22:08 Dr Maxim Orlovsky
2019-08-21 4:14 ` ZmnSCPxj
2019-08-21 7:32 ` ZmnSCPxj
2019-08-21 9:33 ` Stefan Richter
2019-08-21 17:04 ` Dr Maxim Orlovsky [this message]
2019-08-21 10:51 ` Dr Maxim Orlovsky
2019-08-21 12:48 ` ZmnSCPxj
[not found] ` <A733B8A1-2E88-47F4-A6CF-C56C84E8FF9A@pandoracore.com>
2019-08-21 12:12 ` ZmnSCPxj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='yBkmyGw473TegSTQPwap9mH7xT4yHWeFBAuq7Whztr56CPIMeN4Ld0edRg9uGnvTGhUy_GML8pM9XHnIHPxBc4Cv0MVejhlclbC_6eMFsKI=@protonmail.com' \
--to=orlovsky@protonmail$(echo .)com \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox