anders94
commented
3 years ago Yeah, interesting you bring this up - James and I have had a few discussions about the first one. I think the watchtower is really just a set of functionality, not necessarily a separate system so you could fold it in. Shouldn't change the tx format, just the interaction strategy. Also, if interaction is syncronous or asyncronous I think it also just an implementation detail. If you want to pick off a service the banks could supply, it would be making an async process appear sync as you describe above.
I think the question with number 2 is "how long". With the watchtower, that is "forever" but it could intellegently push off older data to more sedintary storage (we've discussed this a bit) and then you just wait a little longer to get it from the watchtower. (or watchtower part of the sentinel)
To me it seems more of an implementation detail rather than something we'd do for phase 2 but clearly lots of area for improvement in the interaction, no question.
HalosGhost
Sharing a couple ideas I had on changing the architecture to simplify transaction protocols for users
1) Simplify confirmation process for wallets by shifting responsibility to the sentinels: In both architectures, any querying of the watchtower could be shifted to the sentinel. Sentinels would be a one-stop stop for users submitting or wanting to know the status of a transaction. For the submitter, the sentinel would keep the client connection open (same as 2PC currently) and would query the watchtower within a time-out window to check its status. It could similarly query for or track any error messages if the transaction fails. For the receiver, the sentinel would perform the same function by forwarding their query to the watchtower. Sentinels could scale in parallel to accommodate this functionality without any major impact on system performance
2) Solve the output sharing problem while maintaining privacy by having temporary (<5 minute) transaction storage at the sentinel layer. Our system requires out-of-band communication of outputs despite this data being seen by the sentinel. Recipients (or whoever doesn't submit the transaction) could sign a transaction status query to the sentinel containing their public key and a signature proving their identity. The sentinel layer would either direct the query to the correct sentinel or some temporary transaction data storage service, which would match the query's public key with recent transactions, including the outputs, transaction ID, and status information. The sentinel layer would delete transaction data either after one or both public keys have queried it OR at an upper bound of X minutes. This prevents long term data storage that would have privacy implications, isolates the performance impact, and simplifies the transaction protocol for users (likely improving usability)