Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A76554A3; Mon, 30 Apr 2018 17:29:00 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 100D45D3; Mon, 30 Apr 2018 17:28:59 +0000 (UTC) Received: by mail-wm0-f44.google.com with SMTP id x12so12187293wmc.0; Mon, 30 Apr 2018 10:28:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=ky0ZW3ibgxKK26yl9wPsJABBKcZbAtiPEll7lFLeLk8=; b=F0jTiU48mxE4ZREXL6WPLDqTSk5BmWIIQt3vaoWIamQhNAtppTQCCVLgMn5uvlApW4 U6y5W2fnQgEFU9YHMjAJno8olMxwkt1RIW3ha/HRurusF5F+s4ZFZpP8IOLkhtHQKKUn +k08771m/TOPnwKzFwZvwRv5CczE6REAR/X/XESPTKkt2AjdpZ105LVcrJd/z9cf96Rb XQI8RE2gWnNVyorYmoHO9WTB5Ba+bfcM5aezAV/BIiGwDvJVlgFQ9dq8BoEPKK5d0tiC Un+QH+qEuwwj3pok3f7nSUxRecKSBpDEJJFqE4fITXrTvVh0AUFOLpqdeLv+V4i9bRgH /Kng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=ky0ZW3ibgxKK26yl9wPsJABBKcZbAtiPEll7lFLeLk8=; b=GoXrwEofLNMWjakDFO6BIqphDimoyvfOS/AfELQSrGzrECYnwwhSnO1cvxf4TVnNjR EcClbMHzYvRIOrBzzwYm45CIozwQ7R4a+jogUYja15P1vyoE0azbYwU9CMf1aapUKQEx OjubSuk3cjiuvd3nRDhIsWAf3mQMPXZ5pVpHUhofbE0nbHuv+dgMKhux+zUzeDrQKWuW brrOAyn3wI3AFupcuuQhqoYKf4K+zvx2g3afQpNxTKMwc2XBFHiQITmj3mWRVDOlLtid 8qfdh7/8YWs6m57WwJx6hXpEXZKqekdoZCEcEdMfGnLl5QByV5yPvYiLiGW//pr7GF+M GIiA== X-Gm-Message-State: ALQs6tAh+75aqSUfMfTObxCkWM3ICLX/sFEdw38fR8Cl6VoorjgyCcMs hiuOMc2YqslXKjWggaGe5JIxbcrw X-Google-Smtp-Source: AB8JxZpHLs2kitwO7z2V45upENANa91eKubE0BRusJg5GDl9s2z5nV7qu/8zo6Ew+q/yw3mf+4Wy1g== X-Received: by 10.28.128.14 with SMTP id b14mr8370723wmd.143.1525109338351; Mon, 30 Apr 2018 10:28:58 -0700 (PDT) Received: from localhost ([2a02:aa16:1102:5480:e99:3f63:40a2:83e9]) by smtp.gmail.com with ESMTPSA id b185sm7698881wmb.25.2018.04.30.10.28.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Apr 2018 10:28:57 -0700 (PDT) From: Christian Decker To: lightning-dev@lists.linuxfoundation.org, bitcoin-dev@lists.linuxfoundation.org Date: Mon, 30 Apr 2018 18:29:53 +0200 Message-ID: <871sewirni.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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 Subject: [bitcoin-dev] BIP 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: Mon, 30 Apr 2018 17:29:00 -0000 Hi all, I'd like to pick up the discussion from a few months ago, and propose a new sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the previous output. This was previously mentioned on the list by Joseph Poon [1], but was never formally proposed, so I wrote a proposal [2]. We have long known that `SIGHASH_NOINPUT` would be a great fit for Lightning. They enable simple watch-towers, i.e., outsource the need to watch the blockchain for channel closures, and react appropriately if our counterparty misbehaves. In addition to this we just released the eltoo [3,4] paper which describes a simplified update mechanism that can be used in Lightning, and other off-chain contracts, with any number of participants. By not committing to the previous output being spent by the transaction, we can rebind an input to point to any outpoint with a matching output script and value. The binding therefore is no longer explicit through a reference, but through script compatibility, and the transaction ID reference in the input is a hint to validators. The sighash flag is meant to enable some off-chain use-cases and should not be used unless the tradeoffs are well-known. In particular we suggest using contract specific key-pairs, in order to avoid having any unwanted rebinding opportunities. The proposal is very minimalistic, and simple. However, there are a few things where we'd like to hear the input of the wider community with regards to the implementation details though. We had some discussions internally on whether to use a separate opcode or a sighash flag, some feeling that the sighash flag could lead to some confusion with existing wallets, but given that we have `SIGHASH_NONE`, and that existing wallets will not sign things with unknown flags, we decided to go the sighash way. Another thing is that we still commit to the amount of the outpoint being spent. The rationale behind this is that, while rebinding to outpoints with the same value maintains the value relationship between input and output, we will probably not want to bind to something with a different value and suddenly pay a gigantic fee. The deployment part of the proposal is left vague on purpose in order not to collide with any other proposals. It should be possible to introduce it by bumping the segwit script version and adding the new behavior. I hope the proposal is well received, and I'm looking forward to discussing variants and tradeoffs here. I think the applications we proposed so far are quite interesting, and I'm sure there are many more we can enable with this change. Cheers, Christian [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012460.html [2] https://github.com/cdecker/bips/blob/noinput/bip-xyz.mediawiki [3] https://blockstream.com/2018/04/30/eltoo-next-lightning.html [4] https://blockstream.com/eltoo.pdf