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

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

[Jose Femenias]

[-- Attachment #1: Type: text/html, Size: 2735 bytes --]

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

[Tim Blokdijk]

[-- Attachment #1: Type: text/plain, Size: 1964 bytes --]

Hello José,

Just a quick question, this is fully decentralized?

Greetings,

Tim Blokdijk

Op 02-12-19 om 15:00 schreef Jose Femenias via bitcoin-dev:
> Hi,
>
> I have just released an early preview of easypaysy, a protocol for 
> Bitcoin, that I have been working on for the past few months.
>
> (In case you are wondering, easypaysy stands for EASY - PAYment- 
> SYstem...)
>
> Long story short, easypaysy is a layer-two protocol that allows the 
> creation of non-custodial accounts directly on the blockchain, so that 
> bitcoin addresses can fully disappear from the user experience.
> In lieu of addresses, users send payments to permanent account IDs.
>
> Account IDs are implicitly assigned by the mining process, and come in 
> several flavors, like in these examples:
>
> Canonical ID: btc@543847.636/577
> Mnemonic ID: btc@cancel-mind.exhibit/motion
> Domain ID: btc@example.com/motion-custom
>
> (Note: Domain IDs are optional and require extra configuration)
>
> The protocol allows both interactive and non interactive payments.
> All payments are non-repudiable, and it is possible to implement 
> pull-payments as well as chargebacks.
>
> Most of the protocol is quite advanced, but I have refrained from 
> specifying some of the details, until the interested parties can give 
> their feedback.
>
> For more information, you can see the white paper and a short 
> introductory video at:
>
> https://www.easypaysy.org
>
> or directly, by following these links:
>
> White paper at https://www.easypaysy.org/assets/easypaysy_white_paper.pdf
> Introductory video at https://www.youtube.com/watch?v=AOGBdyZbyoA
>
> You can also get in contact with me in at:
>
> jose.femenias@gmail.com
>
> or using the project's email at:
>
> easypaysy@gmail.com
>
> Best regards.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 4061 bytes --]

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

[ZmnSCPxj]

Good morning Tim, and Jose,

> Just a quick question, this is fully decentralized?
>

It broadcasts information over `OP_RETURN` on the blockchain layer, thus decentralized as long as the blockchain layer is decentralized.
It also means that to register an account, you need to either own some Bitcoins, or rent some Bitcoins to serve as signalling (and then potentially have to change your account identifier later when the lease expires).
`OP_RETURN` does have size limits (imposed by `isStandard`), I do not remember exact numbers, and any data would need to fit.
Finally, use of the blockchain layer is costly; given that payees must be online at any time payers wish to pay, it may do better to just use Lightning instead, which has the same requirement, but moves payments to a separate layer as well, and requires only a single onchain transaction to construct a channel (easypaysy seems to require at least 2, one to anchor the account pubkeys, the other to give the basic "activation" information for the account).

It may be useful to consider defiads, which does *not* use `OP_RETURN`, but instead uses pay-to-contract, and sends the advertisement data over a separate overlay network.
The use-case is mildly different, but ultimately defiads is about connecting potential buyers to potential sellers, and sending data about how to get paid would have to be part and parcel of how defiads ultimately works.

Also, one of the contact-information protocols supported should probably be Tor hidden services, instead of `https`.
Tor hidden services have better useability (no need for port forwarding or registering DNS from some centralized service), with privacy as a bonus.

Further it seems insufficient to only encode block and tx index.
I think it should also encode output index, to also allow a single transaction to anchor multiple accounts.
Also consider using the Lightning encoding of identifying an output: 543847x636x2


Regards,
ZmnSCPxj


> Greetings,
>
> Tim Blokdijk
>
> Op 02-12-19 om 15:00 schreef Jose Femenias via bitcoin-dev:
>
> > Hi,
> >
> > I have just released an early preview of easypaysy, a protocol for Bitcoin, that I have been working on for the past few months.
> >
> > (In case you are wondering, easypaysy stands for EASY - PAYment- SYstem...)
> >
> > Long story short, easypaysy is a layer-two protocol that allows the creation of non-custodial accounts directly on the blockchain, so that bitcoin addresses can fully disappear from the user experience.
> > In lieu of addresses, users send payments to permanent account IDs.
> >
> > Account IDs are implicitly assigned by the mining process, and come in several flavors, like in these examples:
> >
> > Canonical ID:    btc@543847.636/577
> > Mnemonic ID:    btc@cancel-mind.exhibit/motion
> > Domain ID:    btc@example.com/motion-custom
> >
> > (Note: Domain IDs are optional and require extra configuration)
> >
> > The protocol allows both interactive and non interactive payments.
> > All payments are non-repudiable, and it is possible to implement pull-payments as well as chargebacks.
> >
> > Most of the protocol is quite advanced, but I have refrained from specifying some of the details, until the interested parties can give their feedback.
> >
> > For more information, you can see the white paper and a short introductory video at:
> >
> > https://www.easypaysy.org
> >
> > or directly, by following these links:
> >
> > White paper at https://www.easypaysy.org/assets/easypaysy_white_paper.pdf
> > Introductory video at https://www.youtube.com/watch?v=AOGBdyZbyoA
> >
> > You can also get in contact with me in at:
> >
> > jose.femenias@gmail.com
> >
> > or using the project's email at:
> >
> > easypaysy@gmail.com
> >
> > Best regards.
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jose Femenías Cañuelo]

[-- Attachment #1: Type: text/plain, Size: 256 bytes --]

> Hello José,
> 
> Just a quick question, this is fully decentralized?
> Greetings,
> 
> Tim Blokdijk


Tim,

it is fully decentralized indeed. 
Every user is in charge of creating and maintaining his own account.

Regards,

José Femenías

[-- Attachment #2: Type: text/html, Size: 1197 bytes --]

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

[Jose Femenías Cañuelo]

Hi ZmnSCPxj

first of all, excuse me for my delayed answer. 

I think I posted to the wrong address the first time (I’m mainly a lurker in the list, so I make gotchas like that…)

Let me address your points.

> It also means that to register an account, you need to either own some Bitcoins, or rent some Bitcoins to serve as signalling (and then potentially have to change your account identifier later when the lease expires). 

I don’t understand what you mean by ‘renting’ Bitcoins. 
Once you commit the account transaction, the account ID never changes.
(Also, you don’t need to own Bitcoins if you use a Master Easypaysy Account. See my comments later on).



> Finally, use of the blockchain layer is costly; given that payees must be online at any time payers wish to pay, it may do better to just use Lightning instead,

That is not the case. 
When using non-interactive payments, the payee doesn’t need to be online at all.
Even for interactive payments, it depends on the protocol you use.

For Bitmessage, or email, or even MQTT you don’t need to be online simultaneously. (The interactive protocol(s) is still open, however, those are just some hypothetical examples):

Anyway, when using interactive payments, the payee has the option to specify an LN invoice and/or a bitcoin address.



> which has the same requirement, but moves payments to a separate layer as well, and requires only a single onchain transaction to construct a channel (easypaysy seems to require at least 2, one to anchor the account pubkeys, the other to give the basic "activation" information for the account). 

Easypaysy accounts don’t need 2 TXs. They need funding plus a TX for the account information itself.
So, you need an UTXO -to fund the account- and a TX. 
But the UTXO can be one of many in the same transaction. 
So, you could fund multiple accounts with a single TX.


> Also, one of the contact-information protocols supported should probably be Tor hidden services, instead of `https`. Tor hidden services have better useability (no need for port forwarding or registering DNS from some centralized service), with privacy as a bonus. 
Easypaysy is protocol agnostic (for now). So, Tor is definitely a possibility.


> Further it seems insufficient to only encode block and tx index. I think it should also encode output index, to also allow a single transaction to anchor multiple accounts. Also consider using the Lightning encoding of identifying an output: 543847x636x2 
There is really no need to specify an additional output.
If I am right, you can’t have more than one OP_RETURN per transaction.

On the other hand, as you can see in the white paper “4.2 Master accounts”, these type of accounts allow for up to 2048 accounts per transaction.

The format of the ID in this case is: btc@master_idx.slave_id/checksum

The master_idx is an ordinal pointer (not positional) to the Master TX, while the slave_id points to one of the 2048 transactions within the account (whose information is stored elsewhere, protected by a Merkle root committed in the Master Tx)

There is a little bit more to it that seems appropriate to discuss here, please have a look at page 25 of the white paper.

Thanks for your input.


Best regards,

José Femenías

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

[ZmnSCPxj]

Good morning Jose,


> > It also means that to register an account, you need to either own some Bitcoins, or rent some Bitcoins to serve as signalling (and then potentially have to change your account identifier later when the lease expires).
>
> I don’t understand what you mean by ‘renting’ Bitcoins.
> Once you commit the account transaction, the account ID never changes.
> (Also, you don’t need to own Bitcoins if you use a Master Easypaysy Account. See my comments later on).

If you have 0 Bitcoins, you need to have *some* Bitcoins from somewhere else (perhaps a service provider) in order to back the initial funding transaction output.
If you create Master Easypaysy account by paying fiat to some service provider that then uses its Bitcoins to fund your Easypaysy account, but requires some sort of shared control over the money in it, I simply call this "renting" the Bitcoin, as presumably the service provider would want to get its coins back from you.

If you are referring to the use of a service provider, then the service provider at least partially controls your account and if it ceases to exist or refuses to continue doing business with you, you need to transfer your account identifier somehow (i.e. end of lease).

>
> > Finally, use of the blockchain layer is costly; given that payees must be online at any time payers wish to pay, it may do better to just use Lightning instead,
>
> That is not the case.
> When using non-interactive payments, the payee doesn’t need to be online at all.
> Even for interactive payments, it depends on the protocol you use.
>
> For Bitmessage, or email, or even MQTT you don’t need to be online simultaneously. (The interactive protocol(s) is still open, however, those are just some hypothetical examples):

You could indicate use of some kind of pay-to-contract, then have the payer send the contract text to the payee so that the payee can claim the funds later.

> Anyway, when using interactive payments, the payee has the option to specify an LN invoice and/or a bitcoin address.
>
> > which has the same requirement, but moves payments to a separate layer as well, and requires only a single onchain transaction to construct a channel (easypaysy seems to require at least 2, one to anchor the account pubkeys, the other to give the basic "activation" information for the account).
>
> Easypaysy accounts don’t need 2 TXs. They need funding plus a TX for the account information itself.
> So, you need an UTXO -to fund the account- and a TX.

Yes, that is why I count it as 2 transactions: one transaction to host the funding UTXO that is referred to in the account identifier, and the other transaction is what broadcasts the account information (in particular, the funding UTXO is a P2SH and the transaction that spends it is the one that reveals the 2 pubkeys you require).

In contrast, Lightning Network requires only the funding UTXO (which requires that short channel IDs include the transaction output index, as a single funding transaction can fund multiple Lightning Network channels).

> But the UTXO can be one of many in the same transaction.
> So, you could fund multiple accounts with a single TX.

So can Lightning Network channels: multiple channels can be funded by a single funding transactions (C-Lightning supports this, but not as a single command yet, it requires some low-level fiddling).

> > Also, one of the contact-information protocols supported should probably be Tor hidden services, instead of `https`. Tor hidden services have better useability (no need for port forwarding or registering DNS from some centralized service), with privacy as a bonus.
>
> Easypaysy is protocol agnostic (for now). So, Tor is definitely a possibility.

I suggest being Tor-centric instead.

>
> > Further it seems insufficient to only encode block and tx index. I think it should also encode output index, to also allow a single transaction to anchor multiple accounts. Also consider using the Lightning encoding of identifying an output: 543847x636x2
>
> There is really no need to specify an additional output.
> If I am right, you can’t have more than one OP_RETURN per transaction.

This does not mesh with your earlier claim:

> But the UTXO can be one of many in the same transaction.

My understanding is that the account identifier refers to the funding TXO (and funding transactions do not have an `OP_RETURN`, so I fail to see the relevance of that restriction).
If the funding transaction can have many UTXOs that are individually funding TXOs of multiple Easypaysy accounts, then you need to refer to *which* TXO of that funding transaction is what you are using.

>
> On the other hand, as you can see in the white paper “4.2 Master accounts”, these type of accounts allow for up to 2048 accounts per transaction.
>
> The format of the ID in this case is: btc@master_idx.slave_id/checksum
>
> The master_idx is an ordinal pointer (not positional) to the Master TX, while the slave_id points to one of the 2048 transactions within the account (whose information is stored elsewhere, protected by a Merkle root committed in the Master Tx)
>
> There is a little bit more to it that seems appropriate to discuss here, please have a look at page 25 of the white paper.

Why would it not be appropriate?

In case of such a "Master TX", would it be possible for each slave to be independently controlled by a different party?


Regards,
ZmnSCPxj

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

[Jose Femenías Cañuelo]

Hi ZmnSCPxj,

first of all: do you ever sleep?    ;-)


A few points about your reply:

a) The easypaysy white paper isn’t a final set of specifications. 
Instead it is meant as a somewhat detailed draft of the ideas that can drive a working set of specifications.
As such, any qualified input -as in your case- is much welcome, since it can greatly help with the process.



b) Master accounts are included in the white paper as a feature for a future release. 
The roadmap is not set yet, but I’d like to include a first release of the protocol that only covers the most basic features, to make it simpler and safer for wallet developers. 
Master accounts aren’t a priority, since they are more oriented towards scaling the proposal, and that is far from being a problem yet. 
So, this feature is not well defined for now. However, as presented in the white paper, the ‘service provider’ has really no control over your money.

He would basically do a just a few things: 

- Aggregate the account info (up to 2048 individual accounts per master account).
- Hash every account info, sort them, and calculate the Merkle root of a tree containing them all.
- Create a JSON document containing the information of all the sub-accounts included in the pack.
- Make that JSON document publicly available, probably with a https: URL (That’s called an Authoritative server)
- Finally, create and publish a TX that contains a pointer to the Authoritative server, and the Merkle root of the set of accounts.

The service provider would have NO control whatsoever of your funds, nor can he block payments, etc.
There is some sort of delegation, but no trust involved here. The Merkle root protects agains any attempt of tampering with the account data.

The account’s TX won’t ever disappear from the blockchain, so your account info will always be there.
Worst case scenario, the service provider disappears and users can’t download the Json document containing your account information.

To mitigate this issue, the white paper suggests the creation of mirror servers.

Page 27
---------
'The risk that the authoritative server designated within the EASYPAYSY_MASTER_ACCOUNT_DESCRIPTOR could become unavailable can be mitigated with the use of mirror servers.’
...
'It is conceivable that the mirror could charge for this service, perhaps requiring a small LN payment per request, so there will be an economic incentive to preserve the information associated with every master account ever published into the blockchain.’



c) I am a BIG fan of the Lightning network (see the example before). I wouldn’t like to sound as easypaysy promotes on-chain payments vs LN payments.
I still think there is room for both. I guess and hope that LN payments will grow exponentially in the future. 
However, some large transactions and a few other uses cases will probably make more sense on-chain.



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).
*** However ***, your idea is sound and I can see some use cases for both pointing to the input and output of a TX.
In fact, the seed for easypaysy is some work I did previously, called ‘Bitcoin pointers’ (you can search the dev list for the link).
In there, I proposed a fuller set of features for a TX-ID, including both pointing to the input and the output of a TX.

This is an excerpt from the document on canonical pointers:

'It is also possible to refer to an input: and/or  :output within a transaction. 
In our example, the canonical pointers that point to the first input and the second output of that  transaction are, respectively:

	btc@0:170.1/028-588-872 and btc@170.1:1/413-851-608'

Additionally, the specs allow for the use of attributes; quoting again:

'btc@170.1:1/179_address should return 12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S, which is the address of the second output of that transaction’.



e) The white paper barely touches the implications the easypaysy protocol could have for the Lightning Network, other than citing the possibility of receiving an LN invoice within the Payment reply document.
I didn’t really have neither the time, nor the expertise required to explore further applicability for LN, although I can imagine some use cases.
I know you are quite the expert on LN issues, so if you would like to contribute your suggestions on how to shape the protocol in this regard, I will very much welcome your contributions.

If you are interested, please contact me, preferably privately since I wouldn’t want to become much too off topic in this dev-list

Thanks again for your comments.

Regards,


Jose Femenias

jose.femenias@gmail.com
www.easypaysy.org



> On 6 Dec 2019, at 03:53, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
> 
> Good morning Jose,
> 
> 
>>> It also means that to register an account, you need to either own some Bitcoins, or rent some Bitcoins to serve as signalling (and then potentially have to change your account identifier later when the lease expires).
>> 
>> I don’t understand what you mean by ‘renting’ Bitcoins.
>> Once you commit the account transaction, the account ID never changes.
>> (Also, you don’t need to own Bitcoins if you use a Master Easypaysy Account. See my comments later on).
> 
> If you have 0 Bitcoins, you need to have *some* Bitcoins from somewhere else (perhaps a service provider) in order to back the initial funding transaction output.
> If you create Master Easypaysy account by paying fiat to some service provider that then uses its Bitcoins to fund your Easypaysy account, but requires some sort of shared control over the money in it, I simply call this "renting" the Bitcoin, as presumably the service provider would want to get its coins back from you.
> 
> If you are referring to the use of a service provider, then the service provider at least partially controls your account and if it ceases to exist or refuses to continue doing business with you, you need to transfer your account identifier somehow (i.e. end of lease).
> 
>> 
>>> Finally, use of the blockchain layer is costly; given that payees must be online at any time payers wish to pay, it may do better to just use Lightning instead,
>> 
>> That is not the case.
>> When using non-interactive payments, the payee doesn’t need to be online at all.
>> Even for interactive payments, it depends on the protocol you use.
>> 
>> For Bitmessage, or email, or even MQTT you don’t need to be online simultaneously. (The interactive protocol(s) is still open, however, those are just some hypothetical examples):
> 
> You could indicate use of some kind of pay-to-contract, then have the payer send the contract text to the payee so that the payee can claim the funds later.
> 
>> Anyway, when using interactive payments, the payee has the option to specify an LN invoice and/or a bitcoin address.
>> 
>>> which has the same requirement, but moves payments to a separate layer as well, and requires only a single onchain transaction to construct a channel (easypaysy seems to require at least 2, one to anchor the account pubkeys, the other to give the basic "activation" information for the account).
>> 
>> Easypaysy accounts don’t need 2 TXs. They need funding plus a TX for the account information itself.
>> So, you need an UTXO -to fund the account- and a TX.
> 
> Yes, that is why I count it as 2 transactions: one transaction to host the funding UTXO that is referred to in the account identifier, and the other transaction is what broadcasts the account information (in particular, the funding UTXO is a P2SH and the transaction that spends it is the one that reveals the 2 pubkeys you require).
> 
> In contrast, Lightning Network requires only the funding UTXO (which requires that short channel IDs include the transaction output index, as a single funding transaction can fund multiple Lightning Network channels).
> 
>> But the UTXO can be one of many in the same transaction.
>> So, you could fund multiple accounts with a single TX.
> 
> So can Lightning Network channels: multiple channels can be funded by a single funding transactions (C-Lightning supports this, but not as a single command yet, it requires some low-level fiddling).
> 
>>> Also, one of the contact-information protocols supported should probably be Tor hidden services, instead of `https`. Tor hidden services have better useability (no need for port forwarding or registering DNS from some centralized service), with privacy as a bonus.
>> 
>> Easypaysy is protocol agnostic (for now). So, Tor is definitely a possibility.
> 
> I suggest being Tor-centric instead.
> 
>> 
>>> Further it seems insufficient to only encode block and tx index. I think it should also encode output index, to also allow a single transaction to anchor multiple accounts. Also consider using the Lightning encoding of identifying an output: 543847x636x2
>> 
>> There is really no need to specify an additional output.
>> If I am right, you can’t have more than one OP_RETURN per transaction.
> 
> This does not mesh with your earlier claim:
> 
>> But the UTXO can be one of many in the same transaction.
> 
> My understanding is that the account identifier refers to the funding TXO (and funding transactions do not have an `OP_RETURN`, so I fail to see the relevance of that restriction).
> If the funding transaction can have many UTXOs that are individually funding TXOs of multiple Easypaysy accounts, then you need to refer to *which* TXO of that funding transaction is what you are using.
> 
>> 
>> On the other hand, as you can see in the white paper “4.2 Master accounts”, these type of accounts allow for up to 2048 accounts per transaction.
>> 
>> The format of the ID in this case is: btc@master_idx.slave_id/checksum
>> 
>> The master_idx is an ordinal pointer (not positional) to the Master TX, while the slave_id points to one of the 2048 transactions within the account (whose information is stored elsewhere, protected by a Merkle root committed in the Master Tx)
>> 
>> There is a little bit more to it that seems appropriate to discuss here, please have a look at page 25 of the white paper.
> 
> Why would it not be appropriate?
> 
> In case of such a "Master TX", would it be possible for each slave to be independently controlled by a different party?
> 
> 
> Regards,
> ZmnSCPxj

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

[ZmnSCPxj]

Good morning Jose,

> Hi ZmnSCPxj,
>
> first of all: do you ever sleep? ;-)

It seems possible, that, I do not.


> b) Master accounts are included in the white paper as a feature for a future release.
> The roadmap is not set yet, but I’d like to include a first release of the protocol that only covers the most basic features, to make it simpler and safer for wallet developers.
> Master accounts aren’t a priority, since they are more oriented towards scaling the proposal, and that is far from being a problem yet.
> So, this feature is not well defined for now. However, as presented in the white paper, the ‘service provider’ has really no control over your money.
>
> He would basically do a just a few things:
>
> -   Aggregate the account info (up to 2048 individual accounts per master account).
> -   Hash every account info, sort them, and calculate the Merkle root of a tree containing them all.
> -   Create a JSON document containing the information of all the sub-accounts included in the pack.
> -   Make that JSON document publicly available, probably with a https: URL (That’s called an Authoritative server)
> -   Finally, create and publish a TX that contains a pointer to the Authoritative server, and the Merkle root of the set of accounts.
>
>     The service provider would have NO control whatsoever of your funds, nor can he block payments, etc.
>     There is some sort of delegation, but no trust involved here. The Merkle root protects agains any attempt of tampering with the account data.

This does not seem to mesh well with the other non-Master parts of the protocol, where further updates on the single account backed by a funding TXO are performed by spending the funding TXO and creating a transaction with `OP_RETURN`.

In addition, I would like to suggest as well that instead of `OP_RETURN`, you could instead use "sign-to-contract".

Sign-to-contract is simply that, when signing, instead of selecting a random `r` and computing `R` as `R = r * G`, you select a random `r` and a contract or other message `c`, and compute `R` as `R = r * G + h((r * G) | c) * G`.
Then the user can provide the message `c` independently of the signature, via another mechanism, and reveal `r * G` and `c` and point to the signature as a commitment to the message `c`.
Although, it does have the drawback that using sign-to-contract require a different layer / overlay network to broadcast messages `c`, but it does reduce the cost on the blockchain layer, which is always a good thing.
Similar issues are faced by the RGB project, for instance, and defiads explicitly uses a separate overlay network when transmitting advertisements (both RGB and defiads use the opposite pay-to-contract, which tweaks the pubkey rather than the ephemeral `R`).

>
>     The account’s TX won’t ever disappear from the blockchain, so your account info will always be there.
>     Worst case scenario, the service provider disappears and users can’t download the Json document containing your account information.
>
>     To mitigate this issue, the white paper suggests the creation of mirror servers.

How about control transactions on top of the funding txo?
Who is able to make further control transactions?
If the service provider gives the user full control of the control transactions on top of the funding txo, then it outright loses the money it put in the funding txo and might as well operate as a full exchange.
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.


> 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.
If not, then each time a control transaction changes the details of the easypaysy identifier, the identifier itself is changed.0


> If you are interested, please contact me, preferably privately since I wouldn’t want to become much too off topic in this dev-list

I still do not see why it would be off-topic to the devlist.

Regards,
ZmnSCPxj

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

[Jose Femenías Cañuelo]

Hi ZmnSCPxj,


>> It seems possible, that, I do not.

Haha, I’am starting to believe that’s not a joke ...


>> 
>> This does not seem to mesh well with the other non-Master parts of the protocol, where further updates on the single account backed by a funding TXO are performed by spending the funding TXO and creating a transaction with `OP_RETURN`.
>> 
>> 


You are right. The lifecycle of a regular easypaysy account states that you spend its TXO circularly as many times as you want, specifying changes in its OP_RETURN (you can’t change the Identity or Value key).
When you want to revoke an account, you simply spend its last update (if any) to a different address (not the one it was funded originally with).


> How about control transactions on top of the funding txo?
> Who is able to make further control transactions?
> If the service provider gives the user full control of the control transactions on top of the funding txo, then it outright loses the money it put in the funding txo and might as well operate as a full exchange.

Nope, he will keep control of the TXO keys.


> 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)

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.

The sub-account holder would do so by:

a) Funding the multisig 2-of-2 address composed of his Id_key + Value_key, included in the common JSON file, not the Master TX. (And yes, in this event he will need to buy some btc, because life is hard...)
b) Publishing his own update, much like a regular easypaysy account does.

In any case, the account ID never changes, it would always keep pointing to the original place where it appeared on the blockchain. 
User wallets would have to query for the multisig address of a particular account to check whether the account is detached or not.

As as side note, I expect most easypaysy accounts to choose only non-interactive payments, since they have fewer requirements than their interactive counterparts; so -in most cases- the majority of users won’t ever have to update their accounts.

So, even if the ‘service provider’ goes away or becomes uncooperative, it is just business as usual for the sub-account owners, and they can work just fine with the mirrors.

(Again, all of these is speculative for now. I hope scalability will become an issue for easypaysy one day, but I think we’ll have time to work out the best solution by then)



>> In addition, I would like to suggest as well that instead of `OP_RETURN`, you could instead use "sign-to-contract”….

I really need to study this further before I can express an informed opinion on your suggestion.

On the other hand, for Master accounts I don’t think cost or space should be a problem, since both can be shared among up to 2048 sub-accounts.
For regular accounts, it could be.

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. 

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’)
So, you are right in that the funding TXO doesn’t need to be a one-input, two-output transaction.

> If not, then each time a control transaction changes the details of the easypaysy identifier, the identifier itself is changed.

Nope. The easypaysy identifier always points the placement in the blockchain of the first transaction that spends the funding TXO, not the TXO itself (please read page 3, ‘2.3 Account ID’).
Further updates (performed by spending its single non-zero output to the same address) must be verified by wallets (by asking for the payment history of the funding address; but they never change the account ID, by convention).

So, for example, (I’m following the example in page 13 of the white paper):

a) TX #3b00367…4af, in block 859253, that has j outputs and k outputs, has an output (k) that sends funds to the 2-of-2 multisig address ‘3NhgE9…bqs’. 
   This is the address that the Identity_key + Value_key can spend.

b) Several blocks later, TX #2a01fe…aab2, in its single input, spends the TXO with another TXO the same address ‘3NhgE9…bqs’. 
   It sends all of the funds (minus the fee) in its first output (the 2nd is the OP_RETURN).
   This TX (called the ep_root_tx in the protocol) appears in block 859368 at, let’s say position 349. So its permanent ID will be (obviating the checksum): 
   
   btc@859368.349

   This is the ID you share with your potential payers. Whenever they want to send funds to you, they will look up the 349th transaction at block 859368. 
   They don’t need to check the funding TX at all. They only have to check the signature of the ep_root_tx, because that’s the part of the TX where they can find both the Identity_key and the Value_key.
   Since this TX, by definition of the protocol, can only have a single input, there will be a single signature in it, so there is no need for its easypaysy ID to include a pointer to the input in the TX.


c) A few more blocks later, appears TX #72f1ed…bade8 a similar 1-input 2-output TX, that updates its OP_RETURN with a new ‘Rendezvous descriptor’ (in the example, it changes the email endpoint)
d) Finally, the user revokes the account by spending the output in c) to a different address (17He...A45n).


>> If you are interested, please contact me, preferably privately since I wouldn’t want to become much too off topic in this dev-list
> 
> I still do not see why it would be off-topic to the devlist.

Since the easypaysy proposal is about a layer-2 protocol, I am not sure the developers in this list want to see this much detail about something that maybe doesn’t affect them at all.
Hopefully I am wrong and this is relevant for many of the list subscribers.

Again, thanks for your time and contributions.

Best regards,

Jose


> On 6 Dec 2019, at 18:16, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
> 
> Good morning Jose,
> 
>> Hi ZmnSCPxj,
>> 
>> first of all: do you ever sleep? ;-)
> 
> It seems possible, that, I do not.
> 
> 
>> b) Master accounts are included in the white paper as a feature for a future release.
>> The roadmap is not set yet, but I’d like to include a first release of the protocol that only covers the most basic features, to make it simpler and safer for wallet developers.
>> Master accounts aren’t a priority, since they are more oriented towards scaling the proposal, and that is far from being a problem yet.
>> So, this feature is not well defined for now. However, as presented in the white paper, the ‘service provider’ has really no control over your money.
>> 
>> He would basically do a just a few things:
>> 
>> -   Aggregate the account info (up to 2048 individual accounts per master account).
>> -   Hash every account info, sort them, and calculate the Merkle root of a tree containing them all.
>> -   Create a JSON document containing the information of all the sub-accounts included in the pack.
>> -   Make that JSON document publicly available, probably with a https: URL (That’s called an Authoritative server)
>> -   Finally, create and publish a TX that contains a pointer to the Authoritative server, and the Merkle root of the set of accounts.
>> 
>>    The service provider would have NO control whatsoever of your funds, nor can he block payments, etc.
>>    There is some sort of delegation, but no trust involved here. The Merkle root protects agains any attempt of tampering with the account data.
> 
> This does not seem to mesh well with the other non-Master parts of the protocol, where further updates on the single account backed by a funding TXO are performed by spending the funding TXO and creating a transaction with `OP_RETURN`.
> 
> In addition, I would like to suggest as well that instead of `OP_RETURN`, you could instead use "sign-to-contract".
> 
> Sign-to-contract is simply that, when signing, instead of selecting a random `r` and computing `R` as `R = r * G`, you select a random `r` and a contract or other message `c`, and compute `R` as `R = r * G + h((r * G) | c) * G`.
> Then the user can provide the message `c` independently of the signature, via another mechanism, and reveal `r * G` and `c` and point to the signature as a commitment to the message `c`.
> Although, it does have the drawback that using sign-to-contract require a different layer / overlay network to broadcast messages `c`, but it does reduce the cost on the blockchain layer, which is always a good thing.
> Similar issues are faced by the RGB project, for instance, and defiads explicitly uses a separate overlay network when transmitting advertisements (both RGB and defiads use the opposite pay-to-contract, which tweaks the pubkey rather than the ephemeral `R`).
> 
>> 
>>    The account’s TX won’t ever disappear from the blockchain, so your account info will always be there.
>>    Worst case scenario, the service provider disappears and users can’t download the Json document containing your account information.
>> 
>>    To mitigate this issue, the white paper suggests the creation of mirror servers.
> 
> How about control transactions on top of the funding txo?
> Who is able to make further control transactions?
> If the service provider gives the user full control of the control transactions on top of the funding txo, then it outright loses the money it put in the funding txo and might as well operate as a full exchange.
> 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.
> 
> 
>> 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.
> If not, then each time a control transaction changes the details of the easypaysy identifier, the identifier itself is changed.0
> 
> 
>> If you are interested, please contact me, preferably privately since I wouldn’t want to become much too off topic in this dev-list
> 
> I still do not see why it would be off-topic to the devlist.
> 
> Regards,
> ZmnSCPxj



> On 6 Dec 2019, at 18:16, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
> 
> Good morning Jose,
> 
>> Hi ZmnSCPxj,
>> 
>> first of all: do you ever sleep? ;-)
> 
> It seems possible, that, I do not.
> 
> 
>> b) Master accounts are included in the white paper as a feature for a future release.
>> The roadmap is not set yet, but I’d like to include a first release of the protocol that only covers the most basic features, to make it simpler and safer for wallet developers.
>> Master accounts aren’t a priority, since they are more oriented towards scaling the proposal, and that is far from being a problem yet.
>> So, this feature is not well defined for now. However, as presented in the white paper, the ‘service provider’ has really no control over your money.
>> 
>> He would basically do a just a few things:
>> 
>> -   Aggregate the account info (up to 2048 individual accounts per master account).
>> -   Hash every account info, sort them, and calculate the Merkle root of a tree containing them all.
>> -   Create a JSON document containing the information of all the sub-accounts included in the pack.
>> -   Make that JSON document publicly available, probably with a https: URL (That’s called an Authoritative server)
>> -   Finally, create and publish a TX that contains a pointer to the Authoritative server, and the Merkle root of the set of accounts.
>> 
>>    The service provider would have NO control whatsoever of your funds, nor can he block payments, etc.
>>    There is some sort of delegation, but no trust involved here. The Merkle root protects agains any attempt of tampering with the account data.
> 
> This does not seem to mesh well with the other non-Master parts of the protocol, where further updates on the single account backed by a funding TXO are performed by spending the funding TXO and creating a transaction with `OP_RETURN`.
> 
> In addition, I would like to suggest as well that instead of `OP_RETURN`, you could instead use "sign-to-contract".
> 
> Sign-to-contract is simply that, when signing, instead of selecting a random `r` and computing `R` as `R = r * G`, you select a random `r` and a contract or other message `c`, and compute `R` as `R = r * G + h((r * G) | c) * G`.
> Then the user can provide the message `c` independently of the signature, via another mechanism, and reveal `r * G` and `c` and point to the signature as a commitment to the message `c`.
> Although, it does have the drawback that using sign-to-contract require a different layer / overlay network to broadcast messages `c`, but it does reduce the cost on the blockchain layer, which is always a good thing.
> Similar issues are faced by the RGB project, for instance, and defiads explicitly uses a separate overlay network when transmitting advertisements (both RGB and defiads use the opposite pay-to-contract, which tweaks the pubkey rather than the ephemeral `R`).
> 
>> 
>>    The account’s TX won’t ever disappear from the blockchain, so your account info will always be there.
>>    Worst case scenario, the service provider disappears and users can’t download the Json document containing your account information.
>> 
>>    To mitigate this issue, the white paper suggests the creation of mirror servers.
> 
> How about control transactions on top of the funding txo?
> Who is able to make further control transactions?
> If the service provider gives the user full control of the control transactions on top of the funding txo, then it outright loses the money it put in the funding txo and might as well operate as a full exchange.
> 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.
> 
> 
>> 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.
> If not, then each time a control transaction changes the details of the easypaysy identifier, the identifier itself is changed.0
> 
> 
>> If you are interested, please contact me, preferably privately since I wouldn’t want to become much too off topic in this dev-list
> 
> I still do not see why it would be off-topic to the devlist.
> 
> Regards,
> ZmnSCPxj
> 

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

[ZmnSCPxj]

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