<div dir="ltr">Something like this might also be useful for several use cases related to RBF. For example:<div><br></div><div>Alice sends Bob an RBF-activated transaction T1 with the intention of bumping its fee if necessary. Bob wants to send these funds to Carol, but cannot wait until T1 confirms, so he crafts a transaction T2 that spends T1 using SIGHASH_NOINPUT, and <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">pays Carol</span>. Carol can now make sure she receives the money even if Alice fee-bumps T1, as long as the outputs of the replaced transactions are compatible.</div><div><br></div><div>Extra care should be taken to avoid rebinding, maybe by including an extra input in T2 that doesn&#39;t useĀ <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">SIGHASH_NOINPUT.</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 30, 2018 at 1:29 PM, Christian Decker via bitcoin-dev <span dir="ltr">&lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
I&#39;d like to pick up the discussion from a few months ago, and propose a new<br>
sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the previous<br>
output. This was previously mentioned on the list by Joseph Poon [1], but was<br>
never formally proposed, so I wrote a proposal [2].<br>
<br>
We have long known that `SIGHASH_NOINPUT` would be a great fit for Lightning.<br>
They enable simple watch-towers, i.e., outsource the need to watch the<br>
blockchain for channel closures, and react appropriately if our counterparty<br>
misbehaves. In addition to this we just released the eltoo [3,4] paper which<br>
describes a simplified update mechanism that can be used in Lightning, and other<br>
off-chain contracts, with any number of participants.<br>
<br>
By not committing to the previous output being spent by the transaction, we can<br>
rebind an input to point to any outpoint with a matching output script and<br>
value. The binding therefore is no longer explicit through a reference, but<br>
through script compatibility, and the transaction ID reference in the input is a<br>
hint to validators. The sighash flag is meant to enable some off-chain use-cases<br>
and should not be used unless the tradeoffs are well-known. In particular we<br>
suggest using contract specific key-pairs, in order to avoid having any unwanted<br>
rebinding opportunities.<br>
<br>
The proposal is very minimalistic, and simple. However, there are a few things<br>
where we&#39;d like to hear the input of the wider community with regards to the<br>
implementation details though. We had some discussions internally on whether to<br>
use a separate opcode or a sighash flag, some feeling that the sighash flag<br>
could lead to some confusion with existing wallets, but given that we have<br>
`SIGHASH_NONE`, and that existing wallets will not sign things with unknown<br>
flags, we decided to go the sighash way. Another thing is that we still commit<br>
to the amount of the outpoint being spent. The rationale behind this is that,<br>
while rebinding to outpoints with the same value maintains the value<br>
relationship between input and output, we will probably not want to bind to<br>
something with a different value and suddenly pay a gigantic fee.<br>
<br>
The deployment part of the proposal is left vague on purpose in order not to<br>
collide with any other proposals. It should be possible to introduce it by<br>
bumping the segwit script version and adding the new behavior.<br>
<br>
I hope the proposal is well received, and I&#39;m looking forward to discussing<br>
variants and tradeoffs here. I think the applications we proposed so far are<br>
quite interesting, and I&#39;m sure there are many more we can enable with this<br>
change.<br>
<br>
Cheers,<br>
Christian<br>
<br>
[1] <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012460.html" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/pipermail/bitcoin-dev/<wbr>2016-February/012460.html</a><br>
[2] <a href="https://github.com/cdecker/bips/blob/noinput/bip-xyz.mediawiki" rel="noreferrer" target="_blank">https://github.com/cdecker/<wbr>bips/blob/noinput/bip-xyz.<wbr>mediawiki</a><br>
[3] <a href="https://blockstream.com/2018/04/30/eltoo-next-lightning.html" rel="noreferrer" target="_blank">https://blockstream.com/2018/<wbr>04/30/eltoo-next-lightning.<wbr>html</a><br>
[4] <a href="https://blockstream.com/eltoo.pdf" rel="noreferrer" target="_blank">https://blockstream.com/eltoo.<wbr>pdf</a><br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</blockquote></div><br></div>