Re: [bitcoin-dev] easypaysy - A layer-two protocol to send payments without addresses

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

Good morning Jose,




> > If the service provider retains even partial control, then it can refuse to cooperate with the user and the user will be unable to update his or her account.
> > This is not fixable by the use of mirror servers.
>
> You are right about that too… (I wonder if some kind of MAST smart contract could fix this, maybe you have a suggestion for this; I am thinking K of M users can override the service provider if he misbehaves)

Sybils are trivial, and a "quorum" of K users can always be manufactured for a targeted attack.
Far better to use an n-of-n, with the service provider as one of the n, and use pre-signed transactions like in Lightning Network to allow unilateral ending of the agreement.

> What I have in mind, but haven’t completely figured out, in case of an uncooperative service provider -or just because one user decides to fly solo- is the possibility for a sub-account to ‘detach’ itself from the master account.

A "graftroot transform" can be done, at the cost of moving data offchain and thus requiring easypaysy to have its own overlay network.
Basically, one commits onchain (via `OP_RETURN`, sign-to-contract, pay-to-contract, or even just using P2PKH) some public key and a series of `R` values.
Then, control messages are authorized by signatures validated with the public key, and use up individual `R`s in the series of `R` values.
(Alternately we commit just to the public key and a "next" `R` value, and each control message indicates a new public key and next `R` value that is signed with the current public key and "current" `R` value, to form a chain of off-blockchain control messages.)

Having a precommitted series of `R` values ensures that the signer can only safely use an `R` once and thus cannot otherwise attack the network by giving half of it one control message and the other half a conflicting control message: if someone does so, the `R` must be reused between both conflicting control messages and this allows trivial revelation of the private key (i.e. a form of single-use-seal).
Presumably the private key is valuable by itself somehow.

> But, based on the private feedback I am having from two prominent figures in the space, making sure the protocol is easy to implement for SPV wallets is essential to encourage wallet adoption.
> A separate transport layer doesn’t fit well with this.

Indeed.

>
> So, maybe your suggestion will become more applicable in future iterations of the protocol. I may request your help for further clarification about this issue, if you are so kind (as you always are).
>
> > > d) Regarding your comments on the possibility of adding the output index in the account ID, I still don’t see the need for the use case of easypaysy (since, by definition, easypaysy accounts must have exactly one input and two outputs).
> >
> > Do you mean, that if the user makes a control transaction to change the details of the account, then the user is forced to change the easypaysy identifier?
> > My initial reading of your whitepaper is that the easypaysy identifier refers to the funding txo that roots the further control transactions.
> > If so, the funding txo is not necessarily a one-input two-output transaction.
>
> The easypaysy identifier doesn’t point to the funding TXO. Instead it points to the first transaction that spends the funding TXO (the TX with the OP_RETURN containing the ‘Rendezvous descriptor’)

Ah, I see my misunderstanding now.

Regards,
ZmnSCPXj