Re: [Lightning-dev] [bitcoin-dev] BIP sighash_noinput

DING FENG writes: > Hi, > > I'm a junior developer and a bitcoin user. > And I have read this thread carefully. > > I'm very worried about "SIGHASH_NOINPUT". > > Because "SIGHASH_NOINPUT" looks will be widely used, and it makes reuse > address more dangerous. No. A wallet should *never* create

Re: [Lightning-dev] [bitcoin-dev] BIP sighash_noinput

Good morning DING FENG, While your concern is valid, the general intent is the below: 1. We will use a scary name like SIGHASH_NOINPUT_UNSAFE to explicitly inform to wallet and Bitcoin software developers that the flag is potentially unsafe. 2. SIGHASH_NOINPUT_UNSAFE is intended to be used

Re: [Lightning-dev] [bitcoin-dev] BIP sighash_noinput

Hi, I'm a junior developer and a bitcoin user. And I have read this thread carefully. I'm very worried about "SIGHASH_NOINPUT". Because "SIGHASH_NOINPUT" looks will be widely used, and it makes reuse address more dangerous. Now, most donate addresses (even bitcointalk.org and bitcoin.org) used

Re: [Lightning-dev] [bitcoin-dev] BIP sighash_noinput

On Tue, Jul 03, 2018 at 11:45:22PM +, Gregory Maxwell wrote: > On Tue, Jul 3, 2018 at 5:21 AM, Peter Todd wrote: > > The problem with that name is `SIGHASH_REUSE_VULNERABLE` tells you nothing > > about what the flag actually does. > > I believe that making the signature replayable is 1:1

Re: [Lightning-dev] [bitcoin-dev] BIP sighash_noinput

On Monday 02 July 2018 18:11:54 Gregory Maxwell wrote: > I know it seems kind of silly, but I think it's somewhat important > that the formal name of this flag is something like > "SIGHASH_REPLAY_VULNERABLE" or likewise or at least > "SIGHASH_WEAK_REPLAYABLE". This is because noinput is materially

Re: [Lightning-dev] [bitcoin-dev] BIP sighash_noinput

Gregory Maxwell writes: > I know it seems kind of silly, but I think it's somewhat important > that the formal name of this flag is something like > "SIGHASH_REPLAY_VULNERABLE" or likewise or at least > "SIGHASH_WEAK_REPLAYABLE". This is because noinput is materially > insecure for traditional

Re: [Lightning-dev] [bitcoin-dev] BIP sighash_noinput

A convention in Haskell libraries is to use an "unsafe" prefix to any function that may have side effects (here be dragons, etc) I'm happy with a _VULNERABLE or _UNSAFE postfix as a standard way to signal this. ___ Lightning-dev mailing list

Re: [Lightning-dev] [bitcoin-dev] BIP sighash_noinput

On Tue, Jul 03, 2018 at 02:26:53PM +0930, Rusty Russell via bitcoin-dev wrote: > Gregory Maxwell via bitcoin-dev > writes: > > On Mon, Apr 30, 2018 at 4:29 PM, Christian Decker via bitcoin-dev > > wrote: > >> Hi all, > >> > >> I'd like to pick up the discussion from a few months ago, and

Re: [Lightning-dev] [bitcoin-dev] BIP sighash_noinput

Anthony Towns writes: > On Thu, May 10, 2018 at 08:34:58AM +0930, Rusty Russell wrote: >> > The big concern I have with _NOINPUT is that it has a huge failure >> > case: if you use the same key for multiple inputs and sign one of them >> > with _NOINPUT, you've spent all of

Re: [Lightning-dev] [bitcoin-dev] BIP sighash_noinput

Anthony Towns via bitcoin-dev writes: > On Mon, May 07, 2018 at 09:40:46PM +0200, Christian Decker via bitcoin-dev > wrote: >> Given the general enthusiasm, and lack of major criticism, for the >> `SIGHASH_NOINPUT` proposal, [...] > > So first, I'm not sure

Re: [Lightning-dev] [bitcoin-dev] BIP sighash_noinput

Something like this might also be useful for several use cases related to RBF. For example: 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