From: Christian Decker <decker.christian@gmail•com>
To: Olaoluwa Osuntokun <laolu32@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP sighash_noinput
Date: Thu, 10 May 2018 16:12:21 +0200 [thread overview]
Message-ID: <87y3gr38hm.fsf@gmail.com> (raw)
In-Reply-To: <CAO3Pvs-8cX2Gdgu0cb0LdkY6ErguKkzs8pLZapFTD5JdpGms2A@mail.gmail.com>
Olaoluwa Osuntokun <laolu32@gmail•com> writes:
> Super stoked to see that no_input has been resurrected!!! I actually
> implemented a variant back in 2015 when Tadge first described the
> approach to me for both btcd [1], and bitcoind [2]. The version being
> proposed is _slightly_ differ though, as the initial version I
> implemented still committed to the script being sent, while this new
> version just relies on witness validity instead. This approach is even
> more flexible as the script attached to the output being spent can
> change, without rendering the spending transaction invalid as long as
> the witness still ratifies a branch in the output's predicate.
Yeah, we removed the script commitment out of necessity for eltoo, but
it seems to add a lot of flexibility that might be useful. One
additional use-case that came to mind is having a recovery transaction
for vault-like scenarios, i.e., a transaction that can short-circuit a
thawing process of frozen funds. You'd keep that transaction in a vault,
pre-signed and bind it to whatever action you'd like to interrupt.
> Given that this would introduce a _new_ sighash flag, perhaps we
> should also attempt to bundle additional more flexible sighash flags
> concurrently as well? This would require a larger overhaul w.r.t to
> how sighash flags are interpreted, so in this case, we may need to
> introduce a new CHECKSIG operator (lets call it CHECKSIG_X for now),
> which would consume an available noop opcode. As a template for more
> fine grained sighashing control, I'll refer to jl2012's BIP-0YYY [3]
> (particularly the "New nHashType definitions" section). This was
> originally proposed in the context of his merklized script work as it
> more or less opened up a new opportunity to further modify script
> within the context of merklized script executions. The approach reads
> in the sighash flags as a bit vector, and allows developers to express
> things like: "don't sign the input value, nor the sequence, but sign
> the output of this input, and ONLY the script of this output". This
> approach is _extremely_ powerful, and one would be able to express the
> equivalent of no_input by setting the appropriate bits in the sighash.
I purposefully made the proposal as small and as well defined as
possible, with a number of possible applications to back it, since I
think this might be the best way to introduce a new feature and make it
as uncontroversial as possible. I'm not opposed to additional flags
being deployed in parallel, but they'll need their own justification and
analysis, and shouldn't be rushed just "because we're doing noinput".
Going for a separate op-code is definitely an option we considered, but
just for noinput it'd be duplicating quite a lot of existing
functionality. With additional sighash flags it might become necessary,
but I don't think it is necessary just for noinput.
> Looking forward in hearing y'alls thoughts on this approach, thanks.
>
> [1]: https://github.com/Roasbeef/btcd/commits/SIGHASH_NOINPUT
> [2]: https://github.com/Roasbeef/bitcoin/commits/SIGHASH_NOINPUT
> [3]: https://github.com/jl2012/bips/blob/vault/bip-0YYY.mediawiki#new-nhashtype-definitions
>
> -- Laolu
next prev parent reply other threads:[~2018-05-10 14:12 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-30 16:29 Christian Decker
2018-04-30 18:25 ` Dario Sneidermanis
2018-05-01 16:58 ` Russell O'Connor
2018-05-01 17:32 ` Christian Decker
2018-05-04 9:15 ` ZmnSCPxj
2018-05-04 11:09 ` Christian Decker
2018-05-04 14:25 ` ZmnSCPxj
2018-09-26 9:36 ` Jonas Nick
2018-09-26 19:45 ` Johnson Lau
2018-09-26 20:40 ` Jonas Nick
2018-05-07 19:40 ` Christian Decker
2018-05-07 20:51 ` Bram Cohen
2018-07-03 6:58 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2018-07-03 11:54 ` William Casarin
2018-05-08 14:40 ` [bitcoin-dev] " Anthony Towns
2018-05-09 23:01 ` Olaoluwa Osuntokun
2018-05-09 23:04 ` Rusty Russell
2018-05-14 9:23 ` [bitcoin-dev] [Lightning-dev] " Anthony Towns
2018-05-15 14:28 ` Christian Decker
2018-05-07 23:47 ` [bitcoin-dev] " Olaoluwa Osuntokun
2018-05-10 14:12 ` Christian Decker [this message]
2018-07-02 18:11 ` Gregory Maxwell
2018-07-03 4:56 ` Rusty Russell
2018-07-03 5:21 ` Peter Todd
2018-07-03 23:45 ` Gregory Maxwell
2018-07-09 9:41 ` Peter Todd
2018-07-03 12:05 ` Christian Decker
2018-07-03 12:13 ` [bitcoin-dev] [Lightning-dev] " Luke Dashjr
2018-07-04 18:08 ` fred savage
2018-07-05 8:18 ` vv01f
[not found] ` <CAK_c0Xo0G9-YiOGZK_8WsYNkzjQRaH+u7XOUAozKosggXeXTNg@mail.gmail.com>
2018-07-11 7:43 ` ZmnSCPxj
2018-07-13 0:04 ` Rusty Russell
2018-07-13 9:50 ` fred savage
2018-07-13 11:07 ` Christian Decker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y3gr38hm.fsf@gmail.com \
--to=decker.christian@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=laolu32@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox