Re: [bitcoin-dev] SIGHASH_NOINPUT in Segregated Witness

Joseph Poon via bitcoin-dev writes: > Ideally, a 3rd-party can be handed a transaction which can encompass all > prior states in a compact way. For currently-designed Segregated Witness > transactions, this requires storing all previous signatures, which can

Re: [bitcoin-dev] SIGHASH_NOINPUT in Segregated Witness

On Fri, Feb 26, 2016 at 01:32:34AM +, Gregory Maxwell via bitcoin-dev wrote: > On Fri, Feb 26, 2016 at 1:07 AM, Joseph Poon via bitcoin-dev > wrote: > > I'm interested in input and in the level of receptiveness to this. If > > there is interest, I'll

Re: [bitcoin-dev] SIGHASH_NOINPUT in Segregated Witness

Hi Bryan, On Thu, Feb 25, 2016 at 07:34:24PM -0600, Bryan Bishop wrote: > Well if you are bothering to draft up a BIP about that SIGHASH flag, > then perhaps also consider some other SIGHASH flag types as well while > you are at it? I'll take a look at those proposals when drafting the BIP. I

Re: [bitcoin-dev] SIGHASH_NOINPUT in Segregated Witness

Hi Greg, On Fri, Feb 26, 2016 at 01:32:34AM +, Gregory Maxwell wrote: > I think to be successful we must be absolutely ruthless about changes > that go in there beyond the absolute minimum needed for the safe > deployment of segwit... so I think this should probably be constructed > as a new

Re: [bitcoin-dev] SIGHASH_NOINPUT in Segregated Witness

On Thu, Feb 25, 2016 at 7:07 PM, Joseph Poon wrote: > This would be achieved using a SIGHASH flag, termed SIGHASH_NOINPUT. It > does not include as part of the signature, the outpoint being spent > (txid and index), nor the amount. It however, would include the spent > outpoint's script as part of

Re: [bitcoin-dev] SIGHASH_NOINPUT in Segregated Witness

On Fri, Feb 26, 2016 at 1:07 AM, Joseph Poon via bitcoin-dev wrote: > I'm interested in input and in the level of receptiveness to this. If > there is interest, I'll write up a draft BIP in the next couple days. The design of segwit was carefully

[bitcoin-dev] SIGHASH_NOINPUT in Segregated Witness

As Segregated Witness will be merged soon as a solution for transaction malleability, especially with multi-party adversarial signatures, there may be an additional use case/functionality which is helpful for Lightning Network and possibly other Bitcoin use cases. This requires a new SIGHASH flag