Re: [bitcoin-dev] BIP sighash_noinput
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. 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. 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 On Mon, Apr 30, 2018 at 10:30 AM Christian Decker via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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
Re: [bitcoin-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts
Hi Jimpo, You're correct that the introduction of symmetric state now re-introduces the dependency between the CSV value of the commitment, and the HTLC timeouts. It's worth nothing that this issue existed in an earlier version of the BOLT spec, this was pointed out by Mats in the past: [1][2]. The dependency meant that if we wanted to allow very long CSV time outs (like 1 month +), then this would have the adverse effect of increasing the total CLTV timeout along the entire route. As a result, we moved to the 2-stage HTLC scheme which is now implemented and deployed as a part of BOLT 1.0. It may be the case that in the mid to near future, most implementations aren't concerned about long time locks due to the existence of robust and reliable private outsourcers. As a side effect of the way the symmetric state changes the strategy around breach attempts, we may see more breach attempts (and therefore update transactions) on the chain since attempting to cheat w/ vanilla symmetric state is now "costless" (worst case we just use the latest state, best case I can commit the state better for me. This is in stark contrast to punishment/slashing based approaches where a failed breach attempt results in the cheating party losing all their funds. However, with a commitment protocol that uses symmetric state. The 2-stage HTLC scheme doesn't actually apply. Observe that with Lighting's current asymmetric state commitment protocol, the "clock" starts ticking as soon as the commitment hits the chain, and we follow the "if an output pays to me, it must be delayed as I may be attempting a breach". With symmetric state this no longer applies, the clock instead starts "officially" ticking after the latest update transaction has hit the chain, and there are no further challenges. As a result of this, the commitment transaction itself doesn't need to have any CSV delays within the Script branches of the outputs it creates. Instead, each of those outputs can be immediately be spent as the challenge period has already elapsed, and from the PoV of the chain, this is now the "correct" commitment. Due to this, the HTLC outputs would now be symmetric themselves, and look very much like an HTLC output that one would use in a vanilla on-chain cross-chain atomic swap. [1]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-September/000182.html [2]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000339.html On Tue, May 1, 2018 at 6:15 PM Jim Posen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > OK, I see what you are saying. You are effectively suggesting pipelining > the broadcasts of the update transactions. I think this introduces a > problem that a node in the circuit that withholds the preimage for too long > can force all upstream channels to be closed, at only the expense of their > one upstream channel being closed. I believe such an attack could > significantly disrupt the network. > > Let me elaborate on the way I'm thinking about this: > > So say I'm a routing node with an upstream HTLC with CLTV = X. I need to > ensure that if I learn the preimage, that I have time to broadcast and > confirm an HTLC-success transaction before height X. We'll call this number > of blocks D_success. So if I know the preimage, let's say X - D_success is > the latest height that I can safely broadcast the HTLC-success transaction, > assuming the settlement transaction is already final (ie. the update > transaction is confirmed and the CSV delay has passed). So now I also need > to know when to close the channel with the update transaction. I'll assume > it will take at most D_update blocks from the time I broadcast the update > transaction for it to be mined. So unless the downstream HTLC is already > failed, I should always close the upstream channel at height X - D_success > - CSV_update - D_update. > > Now we'll look at the downstream HTLC with CLTV = Y. In order to minimize > the safe delta between the upstream and downstream CLTVs, I will want to > broadcast and confirm an HTLC-timeout transaction as soon after height Y as > possible. So assuming that the downstream settlement transaction is final > at height Y and it takes at most D_timeout blocks for the HTLC timeout > transaction to confirm once it is final assuming no double spends, then Y + > D_timeout is very latest I might learn the payment preimage from the > downstream channel on-chain. So I should be safe as long as X - D_success > > Y + D_timeout. This assumes that the update transaction for the downstream > channel is already mined and the CSV has passed. However, we know from > above that I had to close the upstream channel at time X - D_success - > CSV_update - D_update, which may very well be before Y. So if the > downstream hop waits until just before Y to publish the preimage, they can > force me to close my upstream channel. This applies transitively for > further upstream hops, assuming a large enough CSV va
Re: [bitcoin-dev] BIP sighash_noinput
Given the general enthusiasm, and lack of major criticism, for the `SIGHASH_NOINPUT` proposal, I'd like to formally ask the BBEs (benevolent BIP editors) to be assigned a BIP number. I have hacked together a simple implementation of the hashing implementation in Bitcoin Core [1] though I think it's unlikely to sail through review, and given the lack of ground-work on witness V1 scripts, I can't really test it now, and only the second commit is part of the implementation itself. One issue that was raised off list was that some fork coins have used sighash 0x40 as FORKID. This does not conflict with this proposal since the proposal only applies to segwit transactions, which the fork coins have explicitly disabled :-) I'm looking forward to discussing how to we can move forward to implementing this proposal, and how we can combine multiple proposals into the next soft-fork. Cheers, Christian [1] https://github.com/cdecker/bitcoin/tree/noinput ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
