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

2018-07-13 Thread Christian Decker via bitcoin-dev
fred savage via bitcoin-dev writes: > the issues with sighash_noinput is this > > 1. you cannot prevent address-reuse. because bitcoin is a PUSH > payment. meaning other people can send funds to one address without > the owner of the key approval/refusal. thus luke cannot control >

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

2018-07-13 Thread fred savage via bitcoin-dev
of Rusty Russell via bitcoin-dev Sent: 13 July 2018 00:04:14 To: DING FENG; Luke Dashjr Cc: Bitcoin Protocol Discussion; lightning-...@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput DING FENG writes: > Hi, > > I'm a junior developer and a bitcoin user

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

2018-07-12 Thread Rusty Russell via bitcoin-dev
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: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput

2018-07-11 Thread ZmnSCPxj via bitcoin-dev
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: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput

2018-07-06 Thread vv01f via bitcoin-dev
You can provide a reusable payment code (BIP-47) instead of an actual address. Unfortunately that not yet supported by the clients/apps most people use. Just that would be less a hurdle than providing a service that e.g. generates addresses from xpub. Am July 4, 2018 6:08:43 PM UTC schrieb

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

2018-07-05 Thread fred savage via bitcoin-dev
on behalf of Luke Dashjr via bitcoin-dev Sent: 03 July 2018 12:13:44 To: lightning-...@lists.linuxfoundation.org Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput On Monday 02 July 2018 18:11:54 Gregory Maxwell wrote: > I know it seems kind of si

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

2018-07-03 Thread William Casarin via bitcoin-dev
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. ___ bitcoin-dev mailing list

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

2018-07-03 Thread ZmnSCPxj via bitcoin-dev
Good morning, >The problem with that name is `SIGHASH_REUSE_VULNERABLE` tells you nothing >about what the flag actually does. SIGHASH_NOINPUT_REUSE_VULNERABLE? SIGHASH_NOINPUT_VULNERABLE? Regards, ZmnSCPxj___ bitcoin-dev mailing list

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

2018-07-03 Thread Luke Dashjr via bitcoin-dev
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: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput

2018-05-15 Thread Christian Decker via bitcoin-dev
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: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput

2018-05-14 Thread Anthony Towns via bitcoin-dev
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 them. The current proposal kind-of > > limits the