ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2021-07-27 📝 Original message: Good morning cdecker, aj, ...
📅 Original date posted:2021-07-27
📝 Original message:
Good morning cdecker, aj, and list,
> . In addition we can store the same data with multiple peers, ensuring that as long as one node is behaving we're good.
Depending on size limits of the stored data, it may be possible to use some kind of erasure coding so that at least k of n peers need to be honest so we are good.
I suspect peers would prefer to limit the amount of data they have to store, if they offer this feature, so use of erausre coding seems to be a good idea.
However, since the peer does not know the data you are storing, this detail can be known only by the node saving its data with the peer, so not need to put in specifications.
> I don't think you can reliably hide that you forgot some state? If you
> _did_ forget your state, you'll have forgotten their latest bundle too,
> and it seems like there's at least a 50/50 chance you'd have to send
> them their bundle before they sent you yours?
This objection seems quite correct.
Perhaps it is possible to (mis)use Barrier Escrow: https://suredbits.com/payment-points-implementing-barrier-escrows/
After all, what is needed is a simultaneous way for both sides to provide the data (or admit they lost it) before the other can withhold the data.
1. Both agree on some Barrier Escrow and generate some temporary points.
2. Both sides invoke `barrier-commit` on the Barrier Escrow, receiving E.
3. Both sides *additionally* encrypt the bundle using an asymmetric encryption, which can be decrypted only by anyone who knows `e` such that `E = e * G`.
4. Both sides exchange the asymmetrically-encrypted bundles.
5. Once a side receives the asymmetrically-encrypted bundle from the other side, they invoke `barrier-reveal` using their temporary scalar from #1.
6. When they get `e` from `barrier-reveal` they can decrypt the asymmetric encryption layer from the bundle they receive, then proceed to validate and decrypt the actual encrypted bundle.
If Alice is amnesiac, it just provides a random vector for the "asymmetric encrypted bundle of Bob".
Suppose Bob wants to check if Alice is amnesiac.
Bob cannot delay its send of the Alice-bundle, due to the Barrier Escrow ensuring that both parties have sent *some* bundle.
Thus, even if Bob knows later than Alice has gone amnesiac, by the time Bob knows that, it has handed over the memento of Alice by which Alice can recover.
Bob can send a bogus bundle to Alice, and then if it also receives a bogus bundle, it knows Alice is amnesiac (and it might be a good time to steal from Alice).
ALTERNATELY Alice is *also* trying to probe Bob, so Alice sent a bogus bundle itself.
In that case, Bob could attempt to steal, but runs the risk that Alice was *also* another prober who is not actually amnesiac.
(Not sure if that is valid game theory, though)
On the other hand, Barrier Escrow services have to be paid for their service (else why would they run), and if you have not connected to your peer then you cannot pay for barrier escrow services over Lightning.
Regards,
ZmnSCPxj
📝 Original message:
Good morning cdecker, aj, and list,
> . In addition we can store the same data with multiple peers, ensuring that as long as one node is behaving we're good.
Depending on size limits of the stored data, it may be possible to use some kind of erasure coding so that at least k of n peers need to be honest so we are good.
I suspect peers would prefer to limit the amount of data they have to store, if they offer this feature, so use of erausre coding seems to be a good idea.
However, since the peer does not know the data you are storing, this detail can be known only by the node saving its data with the peer, so not need to put in specifications.
> I don't think you can reliably hide that you forgot some state? If you
> _did_ forget your state, you'll have forgotten their latest bundle too,
> and it seems like there's at least a 50/50 chance you'd have to send
> them their bundle before they sent you yours?
This objection seems quite correct.
Perhaps it is possible to (mis)use Barrier Escrow: https://suredbits.com/payment-points-implementing-barrier-escrows/
After all, what is needed is a simultaneous way for both sides to provide the data (or admit they lost it) before the other can withhold the data.
1. Both agree on some Barrier Escrow and generate some temporary points.
2. Both sides invoke `barrier-commit` on the Barrier Escrow, receiving E.
3. Both sides *additionally* encrypt the bundle using an asymmetric encryption, which can be decrypted only by anyone who knows `e` such that `E = e * G`.
4. Both sides exchange the asymmetrically-encrypted bundles.
5. Once a side receives the asymmetrically-encrypted bundle from the other side, they invoke `barrier-reveal` using their temporary scalar from #1.
6. When they get `e` from `barrier-reveal` they can decrypt the asymmetric encryption layer from the bundle they receive, then proceed to validate and decrypt the actual encrypted bundle.
If Alice is amnesiac, it just provides a random vector for the "asymmetric encrypted bundle of Bob".
Suppose Bob wants to check if Alice is amnesiac.
Bob cannot delay its send of the Alice-bundle, due to the Barrier Escrow ensuring that both parties have sent *some* bundle.
Thus, even if Bob knows later than Alice has gone amnesiac, by the time Bob knows that, it has handed over the memento of Alice by which Alice can recover.
Bob can send a bogus bundle to Alice, and then if it also receives a bogus bundle, it knows Alice is amnesiac (and it might be a good time to steal from Alice).
ALTERNATELY Alice is *also* trying to probe Bob, so Alice sent a bogus bundle itself.
In that case, Bob could attempt to steal, but runs the risk that Alice was *also* another prober who is not actually amnesiac.
(Not sure if that is valid game theory, though)
On the other hand, Barrier Escrow services have to be paid for their service (else why would they run), and if you have not connected to your peer then you cannot pay for barrier escrow services over Lightning.
Regards,
ZmnSCPxj