Re: [Lightning-dev] [bitcoin-dev] Continuing the discussion about noinput / anyprevout

2019-09-30 Thread ZmnSCPxj via Lightning-dev
Good morning list, To elucidate further --- Suppose rather than `SIGHASH_NOINPUT`, we created a new opcode, `OP_CHECKSIG_WITHOUT_INPUT`. This new opcode ignores any `SIGHASH` flags, if present, on a signature, but instead hashes the current transaction without the input references, then check

Re: [Lightning-dev] [bitcoin-dev] Continuing the discussion about noinput / anyprevout

2019-09-30 Thread ZmnSCPxj via Lightning-dev
Good morning Christian, > The concern with output tagging is that it hurts fungibility, marking outputs > used in a contract as such and making them identifiable. But maybe it would be > a good idea to create two domains anyway: one for user-addressable > destinations which users can use with thei

[Lightning-dev] Continuing the discussion about noinput / anyprevout

2019-09-30 Thread Christian Decker
With the recently renewed interest in eltoo, a proof-of-concept implementation [1], and the discussions regarding clean abstractions for off-chain protocols [2,3], I thought it might be time to revisit the `sighash_noinput` proposal (BIP-118 [4]), and AJ's `bip-anyprevout` proposal [5]. (sorry for