From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id BA12FC077D for ; Fri, 6 Dec 2019 02:53:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id A2C6388B81 for ; Fri, 6 Dec 2019 02:53:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+BqV3TbahOc for ; Fri, 6 Dec 2019 02:53:45 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) by hemlock.osuosl.org (Postfix) with ESMTPS id 4975C88A29 for ; Fri, 6 Dec 2019 02:53:45 +0000 (UTC) Date: Fri, 06 Dec 2019 02:53:34 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1575600821; bh=8hih43jqNr2TrMim/5PHNnrlr8GpGK1J7l5Xi9Qgqi8=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID: From; b=eyMgvqsmi4XEyqPyfr/bUGbc2wpI6nIY2FyDD7/nkvjG+SGBXHv1ZfeFurJ5+flK3 xySNeyXZ2fWCmAOLXZZik8hi5G8LkKWSQkc+Pf+EHdunqFemC/7XhCZl+i5ky2keo7 yJ7is+SVdrkSi46EsDEnWYiJFcSCSMuqpRQh56Ro= To: =?UTF-8?Q?Jose_Femen=C3=ADas_Ca=C3=B1uelo?= , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 02:53:47 -0000 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 potentiall= y have to change your account identifier later when the lease expires). > > I don=E2=80=99t understand what you mean by =E2=80=98renting=E2=80=99 Bit= coins. > 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 Easypay= sy Account. See my comments later on). If you have 0 Bitcoins, you need to have *some* Bitcoins from somewhere els= e (perhaps a service provider) in order to back the initial funding transac= tion output. If you create Master Easypaysy account by paying fiat to some service provi= der that then uses its Bitcoins to fund your Easypaysy account, but require= s some sort of shared control over the money in it, I simply call this "ren= ting" 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 pro= vider 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 acc= ount 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 Ligh= tning instead, > > 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. > > For Bitmessage, or email, or even MQTT you don=E2=80=99t need to be onlin= e simultaneously. (The interactive protocol(s) is still open, however, thos= e 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 spec= ify 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 chan= nel (easypaysy seems to require at least 2, one to anchor the account pubke= ys, the other to give the basic "activation" information for the account). > > 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. 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 t= ransaction is what broadcasts the account information (in particular, the f= unding UTXO is a P2SH and the transaction that spends it is the one that re= veals the 2 pubkeys you require). In contrast, Lightning Network requires only the funding UTXO (which requir= es 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 sin= gle funding transactions (C-Lightning supports this, but not as a single co= mmand yet, it requires some low-level fiddling). > > Also, one of the contact-information protocols supported should probabl= y be Tor hidden services, instead of `https`. Tor hidden services have bett= er useability (no need for port forwarding or registering DNS from some cen= tralized service), with privacy as a bonus. > > Easypaysy is protocol agnostic (for now). So, Tor is definitely a possibi= lity. I suggest being Tor-centric instead. > > > Further it seems insufficient to only encode block and tx index. I thin= k it should also encode output index, to also allow a single transaction to= anchor multiple accounts. Also consider using the Lightning encoding of id= entifying an output: 543847x636x2 > > 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 transac= tion. 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 r= elevance of that restriction). If the funding transaction can have many UTXOs that are individually fundin= g TXOs of multiple Easypaysy accounts, then you need to refer to *which* TX= O of that funding transaction is what you are using. > > 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. > > 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, w= hile the slave_id points to one of the 2048 transactions within the account= (whose information is stored elsewhere, protected by a Merkle root committ= ed 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 in= dependently controlled by a different party? Regards, ZmnSCPxj