[dlc-dev] DLCs require long-term off-chain secure data storage

[Jesse Eisenberg]

Thanks everyone for your very useful feedback.

If the "*data users are required to keep is not very sensitive*" would it
be reasonable to store them in a centralized location, perhaps a key-value
store based on a hash of the user's private key? So a central resilient
database of DLC data hosted by a third party in the cloud, that the user's
DLC enabled wallets can look up and read the list of open DLCs they're
participating in? I suppose this would also enable the ability for them to
recover participation in a DLC with only their private key.

This is how defi has evolved until now, and it seems to be the acceptable
amount of risk and functionality users expect and are willing to take.

Are there any other ideas for how to provide a service like this, or
generally how the DLC community advises users to do backups for
long-running DLCs?  SInce the data aren't so sensitive, is the idea that it
just can go to an iCloud style backup? The DLC details, that is, not the
BTC private key.

Thanks!



On Fri, Sep 30, 2022 at 10:44 PM Lloyd Fournier <lloyd.fourn at gmail.com>
wrote:

> Note that with OP_CTV based DLCs you just need to remember the contract
> parameters for the open DLC to be able to claim the coins.
>
> LL
>
> On Thu, 29 Sept 2022 at 19:32, Thibaut Le Guilly <
> thibaut at cryptogarage.co.jp> wrote:
>
>> Hi Jesse,
>>
>> Just to clarify a couple of points:
>>
>> > From my perspective, coming from a background of non-btc decentralized
>> development (web3) this feels odd. If a DLC is open for a year for example,
>> not only do they have to protect their private keys which is a common
>> practice in web3 defi (off-site cold storage, etc) but they have to run a
>> secure resilient database somewhere to track all open DLCs? This doesn't
>> feel like the "decentralized" future.
>>
>> I think it's important to emphasize that apart from the private keys, the
>> data that users are required to keep is not very sensitive as nobody other
>> than them can make use of it, which means it doesn't especially need to be
>> kept on a cold storage.
>>
>> > IIUC this goes for the Oracles as well. A long-term database is needed,
>> and attestation can not be generated from announcements purely by the
>> announcement data and the private key?
>>
>> Oracles don't know anything about the contracts, so actually they don't
>> need to keep anything else than the attestations and private keys, and
>> these are enough to create an attestation (together with the event result
>> of course). The nonces could potentially be stored on a cold wallet as well.
>>
>> Finally I think that what you consider as a drawback is considered by
>> many as a feature. Not having to store the data on-chain means much better
>> privacy and better scalability for the underlying blockchain storage. It
>> does indeed make the client side of the system more complex.
>>
>> Cheers,
>>
>> Thibaut
>>
>> On Thu, Sep 29, 2022 at 7:00 PM Jesse Eisenberg <jesse at dlc.link> wrote:
>>
>>> Hey everyone, I was talking with Tibo today and was surprised to learn
>>> that some data about the DLC needs to be stored on at least one of the two
>>> participating wallets in order to close the DLC later. The private key is
>>> not enough to put the closing transaction onto the BTC blockchain, and the
>>> data can not be recovered by the private key alone.
>>>
>>> From my perspective, coming from a background of non-btc decentralized
>>> development (web3) this feels odd. If a DLC is open for a year for example,
>>> not only do they have to protect their private keys which is a common
>>> practice in web3 defi (off-site cold storage, etc) but they have to run a
>>> secure resilient database somewhere to track all open DLCs? This doesn't
>>> feel like the "decentralized" future.
>>>
>>> A large DLC provider might have a substantial database to protect
>>> (multi-site resiliency etc). And the user might feel obligated to do the
>>> same for their DLCs, as they wouldn't necessarily trust the other party to
>>> close the DLC depending on the payout-related motivations.
>>>
>>> IIUC this goes for the Oracles as well. A long-term database is needed,
>>> and attestation can not be generated from announcements purely by the
>>> announcement data and the private key?
>>>
>>> Do others in the community share this concern? Tibo mentioned that
>>> Lightening also has to keep some data storage, which might make lightening
>>> devs more comfortable with this concept.
>>>
>>> If we think there's a way to lessen the amount of secure storage
>>> off-chain by being able to close a DLC with private-keys only, that seems
>>> like a really useful improvement for my use case.
>>>
>>> Thanks, curious for feedback!
>>>
>>> --Jesse Eisenberg
>>>
>>> Chief Technology Officer
>>>
>>> DLC.Link
>>> jesse at dlc.link
>>> www.dlc.link
>>> [image: twitter] <https://twitter.com/sosaucily>
>>> [image: linkedin] <https://www.linkedin.com/in/jesses16/>
>>>
>>> dlc-dev mailing list
>>> dlc-dev at mailmanlists.org
>>> https://mailmanlists.org/mailman/listinfo/dlc-dev
>>>
>>
>> dlc-dev mailing list
>> dlc-dev at mailmanlists.org
>> https://mailmanlists.org/mailman/listinfo/dlc-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailmanlists.org/pipermail/dlc-dev/attachments/20221001/45ee995f/attachment.htm>