summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJohnson Lau <jl2012@xbt.hk>2018-11-28 16:40:34 +0800
committerbitcoindev <bitcoindev@gnusha.org>2018-11-28 08:40:40 +0000
commitfce0dda13e85ade99affdd347c805293787fd685 (patch)
tree446eb0aa9bba149848d363d822c714732c159fd8
parent5c3dca39916906da099907314163674d642cce44 (diff)
downloadpi-bitcoindev-fce0dda13e85ade99affdd347c805293787fd685.tar.gz
pi-bitcoindev-fce0dda13e85ade99affdd347c805293787fd685.zip
Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT
-rw-r--r--35/19d3de25c5a1a142141773ef2032407178c5e6143
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
+
+
+