From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id EB8C3C077D for ; Fri, 6 Dec 2019 07:56:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id C7A918825E for ; Fri, 6 Dec 2019 07:56:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLc4Z7wjdaSk for ; Fri, 6 Dec 2019 07:56:56 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) by whitealder.osuosl.org (Postfix) with ESMTPS id 7E97487D95 for ; Fri, 6 Dec 2019 07:56:56 +0000 (UTC) Received: by mail-wm1-f45.google.com with SMTP id q9so6770560wmj.5 for ; Thu, 05 Dec 2019 23:56:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=/+JI8+SUVrj7me6sMKYysIRacnr0LMWOwJfLvkWupz0=; b=CBO8cfGPFOYEmFV1YEGS1+xTGCr5SYnzA3qG8DBFQPIgps5zGTkaFXeCFjfC7FzGRM 5EdjPm2aMKVm71nZQg2Fd/6YLIMBlMO0Hg70k1D/6WZCv/UbMrfPt53Qnj40IwDTrDJe Zfy5x0XQDCmmS12dJ8aainrq2HsplsZnI+8PMwWkTZhswCL5nreCM+6hrRHDpjrcSBGf DDxN/MUqQVDTqGr4q09xe1XzbERVsDSiyTeD5e7bk67KPKrksNcrXOJd6APhbZau7Slm bOya42P1R5fKYw8PNbe34g0sHsdj8M4YrzERnHb4flpaY+kyQ9b/Hdo0ds67BuAeBEY4 HRiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=/+JI8+SUVrj7me6sMKYysIRacnr0LMWOwJfLvkWupz0=; b=driZAzUTN65vi9TRq8XnLAQMqfCmLf8kr/JQV8vPd8PlSx4lOXqSXsCaIfMR9Ktg7I klm707KKzAq5io+rC42lLLAbDDF8wcRDFBLZgyFketcE70ofViBO4LstEuU8x24GIOE+ TLkU56bcKlVsRPaFTHNuda7nXd60SELR4sdGl0hw5yJRRfWfP1ns2ex3hT/xpZzOqRMl bNa54VIULyx9HmTrPOeFL12u+/R4I8VCYGlk00Hkr2Dby1EYT+gc/E8BA5NTRiktpI7x xWgb+TiUyxbFQDq2bMm3ADKtyxqBWdTk7oBigqb5On7o3YEk/yXWSJG/+zsmATXhkVNq DzIA== X-Gm-Message-State: APjAAAWTCQ1YeqPOseiSrnB+7lZsaKgx0onOEe3bcUpmE2/CcNOZxAkP 2dqq6kw9Ve+ERFmyBzCRtlE6HeGQ X-Google-Smtp-Source: APXvYqxwQ+2tlSANx5R+NGbjHzYKILknAsoqKB+S0ANEmwPQc0JFwfc3Tqq0YR+lYJxJR1BIs4/FUQ== X-Received: by 2002:a1c:7911:: with SMTP id l17mr9502565wme.44.1575619014437; Thu, 05 Dec 2019 23:56:54 -0800 (PST) Received: from [192.168.1.35] ([178.60.38.49]) by smtp.gmail.com with ESMTPSA id n12sm2546306wmd.1.2019.12.05.23.56.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Dec 2019 23:56:53 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: =?utf-8?Q?Jose_Femen=C3=ADas_Ca=C3=B1uelo?= In-Reply-To: Date: Fri, 6 Dec 2019 08:56:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: bitcoin-dev@lists.linuxfoundation.org X-Mailer: Apple Mail (2.3273) X-Mailman-Approved-At: Fri, 06 Dec 2019 13:40:59 +0000 Subject: Re: [bitcoin-dev] easypaysy - A layer-two protocol to send payments without addresses X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 07:56:58 -0000 Hi ZmnSCPxj, first of all: do you ever sleep? ;-) A few points about your reply: a) The easypaysy white paper isn=E2=80=99t a final set of = specifications.=20 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.=20 The roadmap is not set yet, but I=E2=80=99d 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.=20 Master accounts aren=E2=80=99t a priority, since they are more oriented = towards scaling the proposal, and that is far from being a problem yet.=20= So, this feature is not well defined for now. However, as presented in = the white paper, the =E2=80=98service provider=E2=80=99 has really no = control over your money. He would basically do a just a few things:=20 - 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=E2=80=99s 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=E2=80=99s TX won=E2=80=99t ever disappear from the = blockchain, so your account info will always be there. Worst case scenario, the service provider disappears and users can=E2=80=99= 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.=E2=80=99 ... '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.=E2=80=99 c) I am a BIG fan of the Lightning network (see the example before). I = wouldn=E2=80=99t 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.=20 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=E2=80=99t 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 = =E2=80=98Bitcoin pointers=E2=80=99 (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.=20 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=E2=80=99. 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=E2=80=99t 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=E2=80=99t 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 wrote: >=20 > Good morning Jose, >=20 >=20 >>> 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). >>=20 >> I don=E2=80=99t understand what you mean by =E2=80=98renting=E2=80=99 = Bitcoins. >> Once you commit the account transaction, the account ID never = changes. >> (Also, you don=E2=80=99t need to own Bitcoins if you use a Master = Easypaysy Account. See my comments later on). >=20 > 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. >=20 > 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). >=20 >>=20 >>> 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, >>=20 >> That is not the case. >> When using non-interactive payments, the payee doesn=E2=80=99t need = to be online at all. >> Even for interactive payments, it depends on the protocol you use. >>=20 >> For Bitmessage, or email, or even MQTT you don=E2=80=99t need to be = online simultaneously. (The interactive protocol(s) is still open, = however, those are just some hypothetical examples): >=20 > 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. >=20 >> Anyway, when using interactive payments, the payee has the option to = specify an LN invoice and/or a bitcoin address. >>=20 >>> 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). >>=20 >> Easypaysy accounts don=E2=80=99t 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. >=20 > 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). >=20 > 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). >=20 >> But the UTXO can be one of many in the same transaction. >> So, you could fund multiple accounts with a single TX. >=20 > 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). >=20 >>> 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. >>=20 >> Easypaysy is protocol agnostic (for now). So, Tor is definitely a = possibility. >=20 > I suggest being Tor-centric instead. >=20 >>=20 >>> 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 >>=20 >> There is really no need to specify an additional output. >> If I am right, you can=E2=80=99t have more than one OP_RETURN per = transaction. >=20 > This does not mesh with your earlier claim: >=20 >> But the UTXO can be one of many in the same transaction. >=20 > 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. >=20 >>=20 >> On the other hand, as you can see in the white paper =E2=80=9C4.2 = Master accounts=E2=80=9D, these type of accounts allow for up to 2048 = accounts per transaction. >>=20 >> The format of the ID in this case is: = btc@master_idx.slave_id/checksum >>=20 >> 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) >>=20 >> 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. >=20 > Why would it not be appropriate? >=20 > In case of such a "Master TX", would it be possible for each slave to = be independently controlled by a different party? >=20 >=20 > Regards, > ZmnSCPxj