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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
