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 852AC15D4 for ; Tue, 2 Jul 2019 10:33:49 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 96000834 for ; Tue, 2 Jul 2019 10:33:48 +0000 (UTC) Date: Tue, 02 Jul 2019 10:33:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1562063626; bh=BfZDF7gvi1134aslkxMfOvTXBpXNvwmckDy0Z1fSiV4=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=hqVv2MB7I6Ace0P9McG8Ru2WkYk9hPglpN/QyzeQ9JMhzlTKwH7Jbu/BpA/X/oXke IAvaZdLdbnG2RqC6JIay8y7VqL76RSmz3HtuRT1b4/HdKuxY2tV6KAnuStk+hqZ655 gNtGpHbbHSLL70C8qVwtHN7EtbXDkHCscXWc2XDw= To: Tamas Blummer From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <38FAD812-A764-49F5-BA80-ED10685A1714@gmail.com> References: <0DBC0DEA-C999-4AEE-B2E1-D5337ECD9405@gmail.com> <063D7C06-F5D8-425B-80CE-CAE03A1AAD0C@voskuil.org> <0AA10217-E1CC-46D1-9B43-038CEEF942CD@gmail.com> <0Bwi2ejRw4BgoABZ0X0kBdwLAkIKEv1svoyi0zqGQPeqV1g8xR43tBMgYoS52Vcxkgj7DndmNLIje40au51trIGTvrpcet8GivTgqysVC8w=@protonmail.com> <0190F226-7133-4B6D-8750-25CAB5C73D17@gmail.com> <7E8yyDSqmXEfFtcZRx2vdmPuovamf67X6aDHrokgaYScm01zPivVKpI3Br2PrzBdVdvKBqECP96EFB5ebT8sPfMWU8npJwS_wujFs00bcqU=@protonmail.com> <38FAD812-A764-49F5-BA80-ED10685A1714@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 13:00:30 +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 10:33:49 -0000 Sent with ProtonMail Secure Email. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Tuesday, July 2, 2019 5:30 PM, Tamas Blummer w= rote: > Hello ZmnSCPxj, > > > On Jul 2, 2019, at 10:12, ZmnSCPxj ZmnSCPxj@protonmail.com wrote: > > 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 t= hat unlocks the UTXO for spending. > > By analogy, in my "advertising" scheme, instead of committing the adver= tisement on the UTXO, I can instead commit a public key (for example, the h= ash of the "advertiser pubkey" is used to tweak the onchain public key). > > Then we use this advertiser pubkey to admit advertisements on the adver= tising network. > > This advertiser pubkey is used to sign an "advertisement chain", which = is a merklized singly-linked list whose contents are the actual advertiseme= nts, each node being signed using the advertiser pubkey. > > To ensure that the advertiser does not sign multiple versions of this c= hain, we can have the signing nonce be derived from the height of the adver= tchain, such that signing the same height multiple times leads to private k= ey revelation. > > The advertiser would thereby put the funds of the HODLer on risk of his m= isbehavior, which means the HODLer would have to trust the advertizing serv= ice. No it would not :) Onchain, the locked UTXO would be a 2-of-2 MuSig / 2p-ECDSA of the HODLer a= nd the advertising broker. The HODLer and advertising broker perform a (mostly-offchain) ritual that e= nsures that the HODLer gets a `nLockTime` transaction spending from this UT= XO and paying it back to the HODLer, and that the advertising broker pays f= or rent of this UTXO, prior to the UTXO actually appearing onchain. The UTXO requires both cooperation of HODLer and advertising broker in orde= r to spend, and the HODLer only cares that it gets an `nLockTime` transacti= on and will no longer cooperate / will permanently delete its share of the = key after getting this. The MuSig / 2p-ECDSA pubkey used will then be tweaked (by addition in MuSig= , by multiplication in 2p-ECDSA; the HOLDer need not even learn it, the adv= ertising broker can tweak its pubkey in the Bitcoin-level transaction befor= ehand) to commit to a hash of the "Advertising pubkey". Thus I say the UTXO "commits to the advertising pubkey", not "pays to the a= dvertising pubkey". Indeed, the pubkey of the advertising broker used on the Bitcoin blockchain= can be very different from the advertising pubkey used on the advertchain. This "Advertising pubkey" is the pubkey used in the advertchain. The actual money on Bitcoin cannot be spent by the broker unilaterally. However, what advertisement it will commit to on the advertchain, can be co= ntrolled unilaterally by the advertising broker. That is the entire point: the HODLer rents out the UTXO to the advertising = broker, relinquishes control over the advertchain, but retaining (eventual)= control over the actual Bitcoins. The advertising broker then has sole control of the advertchain, and can re= nt it out for smaller timeframes to actual service/product providers. Regards, ZmnSCPxj