From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 8880E15B3 for ; Tue, 2 Jul 2019 08:12:37 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch [185.70.40.136]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9741D70D for ; Tue, 2 Jul 2019 08:12:36 +0000 (UTC) Date: Tue, 02 Jul 2019 08:12:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1562055154; bh=Wu5tSzH5n0psvWYZ66y5ZUpOvwRS7jNGBJt0ZeHdacI=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=Qb4dTv5cOpJBzYDBHci+UFjLjSglpXtewcU50rcng9sYTFZVRDcUyONqCbVtuT3xj SUFVInlWv+wV/9aEr6rY0g5xCOZ9tq8Keo/jtfp+89jb8aHWjoa2V9IVLyFJR4GgW7 Da1MzTYPR0TkElb22vKro6A1o0Z5p2yydKejJ5xM= To: Tamas Blummer From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <7E8yyDSqmXEfFtcZRx2vdmPuovamf67X6aDHrokgaYScm01zPivVKpI3Br2PrzBdVdvKBqECP96EFB5ebT8sPfMWU8npJwS_wujFs00bcqU=@protonmail.com> In-Reply-To: <0190F226-7133-4B6D-8750-25CAB5C73D17@gmail.com> References: <0DBC0DEA-C999-4AEE-B2E1-D5337ECD9405@gmail.com> <3F46CDD5-DA80-49C8-A51F-8066680EF347@voskuil.org> <063D7C06-F5D8-425B-80CE-CAE03A1AAD0C@voskuil.org> <0AA10217-E1CC-46D1-9B43-038CEEF942CD@gmail.com> <0Bwi2ejRw4BgoABZ0X0kBdwLAkIKEv1svoyi0zqGQPeqV1g8xR43tBMgYoS52Vcxkgj7DndmNLIje40au51trIGTvrpcet8GivTgqysVC8w=@protonmail.com> <0190F226-7133-4B6D-8750-25CAB5C73D17@gmail.com> Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 02 Jul 2019 08:59:10 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 08:12:37 -0000 Good morning Tamas, > Note that the advertizing service provider would need temporary access to= UTXOs of signficant value, so opportunity cost and thereby cost of adverti= zing becomes significant. > Covenants would allow the separation of the advertizing service from HODL= er funding it with significant UTXOs. > HODLer could give temporary control to the service and the service could = broker those to others, but the original HODLer was sure to receive the UTX= Os back and the HODLer would not be bothered with the operation of the serv= ice. Thank you for this thought. It has challenged me to consider how to bring this capability out of the Bi= tcoin blockchain. As a counterargument, I observe that committing to the advertisement on the= UTXO is similar to committing to a SCRIPT on a UTXO. And I observe the Graftroot idea, wherein we commit to a public key on the = UTXO, and admit a SCRIPT that is signed by the public key as a SCRIPT that = unlocks the UTXO for spending. By analogy, in my "advertising" scheme, instead of committing the advertise= ment on the UTXO, I can instead commit a public key (for example, the hash = of the "advertiser pubkey" is used to tweak the onchain public key). Then we use this advertiser pubkey to admit advertisements on the advertisi= ng network. This advertiser pubkey is used to sign an "advertisement chain", which is a= merklized singly-linked list whose contents are the actual advertisements,= each node being signed using the advertiser pubkey. To ensure that the advertiser does not sign multiple versions of this chain= , we can have the signing nonce be derived from the height of the advertcha= in, such that signing the same height multiple times leads to private key r= evelation. Each header of the advertchain also includes a `CLTV`-like construct, which= is the Bitcoin blockheight that must be reached first before another adver= tchain header can be added, containing a new advertisement that replaces th= e previous one. This lets an advertising broker pay for some onchain UTXO to a HODLer, prov= iding a `nLockTime`d onchain transaction returning the funds to the HODLer,= with the UTXO paying to a 2-of-2 with a commitment to the advertiser pubke= y. Then the advertising broker can rent out the UTXO to providers who wish to = advertise, though I have to figure out how to make this atomic (i.e. paying= the advertiser onchain or on Lightning, would be enough for the provider t= o derive the advertchain header and its signature, for its own advertisemen= t --- perhaps some minimal SCRIPT-like language on the advertchain can be d= one). This lets the advertising broker case to work even without generalized cove= nants on the Bitcoin blockchain, while providing the same benefit of not bo= thering the HODLer who ultimately owns the funds each time advertisements n= eed to be changed. This gives the advantage that changes to the advertisement that is attested= by a UTXO do not have any activity on the Bitcoin blockchain itself, only = on the advertchain; at the cost that the advertising network now takes on t= he added bandwidth of handling several tiny blockchains of limited lifetime= , instead of keeping the data on "which advertisement is valid" on the Bitc= oin blockchain. Regards, ZmnSCPxj