From: Ali Sherief <ali@notatether•com>
To: "bitcoin-dev@lists•linuxfoundation.org"
<bitcoin-dev@lists•linuxfoundation.org>,
"burak@buraks•blog" <burak@buraks•blog>
Subject: Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution
Date: Sun, 28 May 2023 06:02:58 +0000 [thread overview]
Message-ID: <-N2f7ihsZ8VYuCRU0KMXQLlw5vwbZ50lAw-MKEFz8838YBuf39SKlf4lNePJUSYQanOuKzFfmZeLFpzeOnbfss7mlhoCvYPwG6a2tt6kfVY=@notatether.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 3263 bytes --]
Burak, I don't remember if this has been mentioned previously in the conversation about Ark, but a disadvantage in the protocol as it is currently is that "Ark require users to come online and "refresh" their coins every few weeks, otherwise the ASP can sweep the funds." (putting that in quotes because although I copied this from a forum, it may have originally been said on this list.)
However, yesterday I have come up with a scheme to mitigate this disadvantage, in a way that works similar to LN watchtowers.
This watchtower program for Ark would be made that runs on an internet-connected server and inputs your wallet password and the date in the future to perform the refreshing. A child process can then be spawned that acts similar to a cronjob, and stores the wallet password with AES encryption in memory.
The key to this cipher is the time stored in ISO 8601 format as a byte string. It is promptly discarded from memory.
Every second, the watchtower child process will attempt to decrypt the cipher using the current ISO 8601 time looking like "YYYY-mm-ddTHH:MM:SSZ" as the key.
Naturally this will only succeed at the requisite time at which the wallet is to be unlocked by the watchtower child process - following which the coins inside the ASP are refreshed, and the watchtower child process is terminated and the encrypted wallet password destroyed.
Of course, memory scrubbing should be applied to the region that has the decrypted wallet password.
If at any point the user comes online by themselves, they can simply cancel the watchtower refreshing task, which will terminate the watchtower child process without opening your wallet and refreshing coins.
The key feature is that nobody will be able to decrypt the wallet password unless they know the exact time it is to be unlocked as an ISO 8601 string. It cannot be unlocked at any time in the future, just at that particular instant, as long as the key is discarded and the software randomly guesses the decryption by attempting each second the new time as the encryption key. Even if the watchtower is hacked after the task has been made, the hacker still won't be able to decrypt the wallet password unless they brute-force the encryption key by exhaustively trying all timestamps in the future.
Alternatively, instead of encrypting the wallet password, it can encrypt a signed transaction which is used by Ark to refresh the coins. In this case, the wallet password would still need to be collected, but only for the purpose of signing the transaction, after which the password is promptly erased from memory.
How this can be extended to repeatedly arming the watchtower program with refreshes remains to be seen, but using the wallet password as the encryption directly is one option albeit not a secure one A better and more secure option would be to take note of the UTXOs created by the coin refreshing transaction, use those as inputs to a second refreshing transaction that is created immediately after the first one, sign it, and similarly create a third, fourth, etc. as many as are desirable for the user. Then every 4 weeks, one of these transactions can be broadcasted, in the order that they were created obviously.
Looking forward to your feedback on this.
-Ali
[-- Attachment #2: Type: text/html, Size: 4819 bytes --]
next reply other threads:[~2023-05-28 6:03 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-28 6:02 Ali Sherief [this message]
-- strict thread matches above, loose matches on Subject: below --
2023-06-11 9:19 moonsettler
2023-06-07 18:20 David A. Harding
2023-05-26 7:33 jk_14
2023-05-25 12:12 Ali Sherief
2023-05-22 7:54 Burak Keceli
2023-05-22 13:03 ` ZmnSCPxj
2023-05-23 4:31 ` Burak Keceli
2023-05-23 22:06 ` G. Andrew Stone
2023-05-24 0:40 ` ZmnSCPxj
2023-05-24 0:45 ` ZmnSCPxj
2023-05-24 7:53 ` Burak Keceli
2023-05-24 6:28 ` Burak Keceli
2023-05-24 20:20 ` adiabat
2023-05-24 23:02 ` David A. Harding
2023-05-26 11:56 ` Burak Keceli
2023-05-27 20:36 ` David A. Harding
2023-06-07 13:30 ` Burak Keceli
2023-08-06 22:43 ` Antoine Riard
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='-N2f7ihsZ8VYuCRU0KMXQLlw5vwbZ50lAw-MKEFz8838YBuf39SKlf4lNePJUSYQanOuKzFfmZeLFpzeOnbfss7mlhoCvYPwG6a2tt6kfVY=@notatether.com' \
--to=ali@notatether$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=burak@buraks$(echo .)blog \
/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