From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: "Jose Femenías Cañuelo" <jose.femenias@gmail•com>
Cc: Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
"bitcoin-dev-request@lists•linuxfoundation.org"
<bitcoin-dev-request@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] easypaysy - A layer-two protocol to send payments without addresses
Date: Sat, 07 Dec 2019 04:09:52 +0000 [thread overview]
Message-ID: <N9-zGG_2BG2WsjQrRXInpHcn53gxQwUb-P9K5P2DL_NoZwYsNAzfgYSvgT4hAyWbmZmshWM5peZKGRmKMfDECvDifwJNUXG7tULEQPLixCU=@protonmail.com> (raw)
In-Reply-To: <6CB7E73C-57C9-428B-83E6-36113B619BFB@gmail.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
next prev parent reply other threads:[~2019-12-07 4:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-05 20:00 Jose Femenías Cañuelo
2019-12-06 2:53 ` ZmnSCPxj
2019-12-06 7:56 ` Jose Femenías Cañuelo
2019-12-06 17:16 ` ZmnSCPxj
2019-12-06 18:47 ` Jose Femenías Cañuelo
2019-12-07 4:09 ` ZmnSCPxj [this message]
-- strict thread matches above, loose matches on Subject: below --
2019-12-02 21:25 Jose Femenías Cañuelo
[not found] <mailman.1377.1575015939.25512.bitcoin-dev@lists.linuxfoundation.org>
2019-12-02 14:00 ` Jose Femenias
2019-12-02 17:27 ` Tim Blokdijk
2019-12-02 21:10 ` ZmnSCPxj
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='N9-zGG_2BG2WsjQrRXInpHcn53gxQwUb-P9K5P2DL_NoZwYsNAzfgYSvgT4hAyWbmZmshWM5peZKGRmKMfDECvDifwJNUXG7tULEQPLixCU=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev-request@lists$(echo .)linuxfoundation.org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jose.femenias@gmail$(echo .)com \
/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