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.femen...@gmail.com
www.easypaysy.org
> On 6 Dec 2019, at 03:53, ZmnSCPxj <zmnsc...@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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
