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 94F179BA for ; Wed, 28 Nov 2018 08:40:40 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender-of-o53.zoho.com (sender-of-o53.zoho.com [135.84.80.218]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 18EFD19B for ; Wed, 28 Nov 2018 08:40:39 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; t=1543394439; cv=none; d=zoho.com; s=zohoarc; b=AGUu07Al2Fo4KiLK2fLCNKXraiCFk7KZFhyMeDrAEOC/aI/13v5fhtdPmKixtB8BlRL2itczi63gwJ9ALbZyrJKU4ZFQr+YHWGs3tHQVMWwLPpG7UaaKVhgFxSsY4MTpL0fD4fAWIzXzd58dxOqJLQok9Ittghv3XlGyXChpHmE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1543394439; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=7qExG0kMac6ZAC/Ine4AHUcZ7kjZB0CNzSSiZRYMm/k=; b=E6dp9nRmWChCPU9voO21OjQY4CIzNMUrlVzpYqxtkxR5eSMnaquTYLH3CiXHYH2v5/wImDt1aXuWywYbNh4XwnafN7wtIkrLqp+jSwcGZgIzf8V6yekTSbAVIuqDzo/rxq0M3eK/CoBKnrmP/UPWDYVm2UJKXP9elr1fdK0eHzQ= ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass header.i=xbt.hk; spf=pass smtp.mailfrom=jl2012@xbt.hk; dmarc=pass header.from= header.from= Received: from [10.7.47.115] (ip-123-255-103-29.wlan.cuhk.edu.hk [123.255.103.29]) by mx.zohomail.com with SMTPS id 15433944376791008.2314816770382; Wed, 28 Nov 2018 00:40:37 -0800 (PST) From: Johnson Lau Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Wed, 28 Nov 2018 16:40:34 +0800 References: <20181128005416.GB22873@mcelrath.org> To: Bob McElrath , bitcoin-dev In-Reply-To: <20181128005416.GB22873@mcelrath.org> Message-Id: <8690D3D0-3815-4779-A571-C75AA75F707B@xbt.hk> X-Mailer: Apple Mail (2.3445.100.39) X-ZohoMailClient: External X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE 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: Wed, 28 Nov 2018 14:24:18 +0000 Subject: Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT 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: Wed, 28 Nov 2018 08:40:40 -0000 This is incompatible with bip-schnorr, which intentionally disallow such = use by always committing to the public key: = https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki With the recent fake Satoshi signature drama, and other potential ways = to misuse and abuse, I think this is a better way to go, which = unfortunately might disallow some legitimate applications. Covenants could be made using OP_CHECKSIGFROMSTACK = (https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf) or = OP_PUSHTXDATA = (https://github.com/jl2012/bips/blob/vault/bip-0ZZZ.mediawiki). I think = this is the next step following the taproot soft fork > On 28 Nov 2018, at 8:54 AM, Bob McElrath via bitcoin-dev = wrote: >=20 > I have been working on an experimental wallet that implements Bitcoin > Covenants/Vaults following a blog post I wrote about 2 years ago, = using > "Pay-to-Timelock Signed Transaction" (P2TST). (Also mentioned = recently by > kanzure in a talk somewheres...) The idea is that you deposit to an = address for > which you don't know the private key. Instead you construct a second > transaction sending that to a timelocked staging address for which you = DO have > the privkey (it also has an IF/ELSE condition with a second spending = condition > for use in case of theft attempt). In order to do this you either = have to > delete the privkey of the deposit address (a difficult proposition to = know it's > actually been deleted), but instead one can construct a signature = directly using > a RNG, and use the SIGHASH to compute the corresponding pubkey via = ECDSA > recover, from which you compute the corresponding address. In this = way your > wallet is a set of P2TST transactions and a corresponding privkey, = with a (set > of) emergency keys. >=20 > This interacts with NOINPUT in the following way: if the input to the > transaction commits to the pubkey in any way, you have a circular = dependency on > the pubkey that could only be satisfied by breaking a hash function. = This > occurs with standard sighash's which commit to the txid, which in turn = commit to > the address, which commits to the pubkey, so this construction of > covenants/vaults requires NOINPUT. >=20 > AFAICT sipa's proposal is compatible with the above vaulted = construction by > using SIGHASH_NOINPUT | SIGHASH_SCRIPTMASK to remove the > scriptPubKey/redeemScript from the sighash. Putting the > scriptPubKey/redeemScript in the sighash introduces the same circular > dependency, but SIGHASH_SCRIPTMASK removes it. >=20 > One would probably want to provide the fee from a separate wallet so = as to be > able to account for fluctuating fee pressures when the unvaulting = occurs a long > time after vaulting. Thus you'd want to use SIGHASH_SINGLE so that a = fee-wallet > can add fees (or for composability of P2TSTs), and SIGHASH_NOFEE as = well. >=20 > P.S. Also very excited to combine the above idea with = Taproot/Graftroot/g'Root. >=20 > -- > Cheers, Bob McElrath >=20 > "For every complex problem, there is a solution that is simple, neat, = and wrong." > -- H. L. Mencken=20 >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev