From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YiE6K-0002FY-LA for bitcoin-development@lists.sourceforge.net; Wed, 15 Apr 2015 03:34:56 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.213.169 as permitted sender) client-ip=209.85.213.169; envelope-from=gmaxwell@gmail.com; helo=mail-ig0-f169.google.com; Received: from mail-ig0-f169.google.com ([209.85.213.169]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YiE6J-0008Ct-Hj for bitcoin-development@lists.sourceforge.net; Wed, 15 Apr 2015 03:34:56 +0000 Received: by igblo3 with SMTP id lo3so31405567igb.0 for ; Tue, 14 Apr 2015 20:34:50 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.42.129.73 with SMTP id p9mr29002808ics.48.1429068890214; Tue, 14 Apr 2015 20:34:50 -0700 (PDT) Received: by 10.107.15.82 with HTTP; Tue, 14 Apr 2015 20:34:50 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 Apr 2015 03:34:50 +0000 Message-ID: From: Gregory Maxwell To: Stephen Morse Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1YiE6J-0008Ct-Hj Cc: bitcoin-development Subject: Re: [Bitcoin-development] Build your own nHashType X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 03:34:56 -0000 On Wed, Apr 8, 2015 at 7:50 PM, Stephen Morse wrote: > Seeking feedback on a proposal that will allow a transaction signer to > explicitly specify what is to be serialized for the signature hash. The > basic idea is to make the nHashType general enough that we won't need a new > sighash flag every time a new use case comes up. > > If implemented into bitcoin (via a soft fork), this would make malleability > almost a non-issue (the TXID referenced by inputs just need to be updated > previous TX changes) and would enable hardware wallets to securely sign > without needing to download/process each transaction it spends from. I'm not sure if I'm super fond of that particular non-programmatic but many options approach; It sort of has the problem that there are relatively few useful options that don't rapidly extend into a choose your own adventure with too many options to count; so you take a complexity penalty perhaps without a matching functionality payoff. but thats not why I'm commenting... I wonder if anyone noticed that any sighash masking that eliminates the txin txid enables covenants? Covenants are payments which constrain their future payments (like deed covenants), I've written about them in the past https://bitcointalk.org/index.php?topic=278122.0 ... they can sometimes be pretty useful but are also potentially a irritating hit to fungibility, at least if used stupidly. the approach here is that you make the scriptpubkey contain "[push: 0x30, 0x06, 0x02, 0x01, 0x04, 0x02, 0x01, 0x04, flags] [push pubkey resulting from pubkey recovery] OP_CHECKSIG" and set the flags to match only the things you want to enforce in the spending transaction hash them up and recover the EC public point. You can think of that construct as giving a you a OP_MASKED_TRANSACTION_HASH_EQUALS ... the recovered pubkey is just a kind of message hash, though a weird and expensive to compute one. I don't currently see how to get a perpetual covenant out of it-- e.g. a coin that anyone can spend, but only to its same scriptpubkey, (the obvious way requires the ability to be able to checksig stuff on the stack) though I wouldn't be shocked if it were possible with a sufficiently complex sighash flag and nothing else.