diff options
author | Johnson Lau <jl2012@xbt.hk> | 2018-11-28 16:40:34 +0800 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2018-11-28 08:40:40 +0000 |
commit | fce0dda13e85ade99affdd347c805293787fd685 (patch) | |
tree | 446eb0aa9bba149848d363d822c714732c159fd8 | |
parent | 5c3dca39916906da099907314163674d642cce44 (diff) | |
download | pi-bitcoindev-fce0dda13e85ade99affdd347c805293787fd685.tar.gz pi-bitcoindev-fce0dda13e85ade99affdd347c805293787fd685.zip |
Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT
-rw-r--r-- | 35/19d3de25c5a1a142141773ef2032407178c5e6 | 143 |
1 files changed, 143 insertions, 0 deletions
diff --git a/35/19d3de25c5a1a142141773ef2032407178c5e6 b/35/19d3de25c5a1a142141773ef2032407178c5e6 new file mode 100644 index 000000000..003f8bb07 --- /dev/null +++ b/35/19d3de25c5a1a142141773ef2032407178c5e6 @@ -0,0 +1,143 @@ +Return-Path: <jl2012@xbt.hk> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 94F179BA + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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=<jl2012@xbt.hk> header.from=<jl2012@xbt.hk> +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 <jl2012@xbt.hk> +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 <bob@mcelrath.org>, + bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 = +<bitcoin-dev@lists.linuxfoundation.org> 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 + + + |