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 a
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 for
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 a
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 with
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 with omitting
the identification of the specific coin being spent from it.
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
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 app
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
Lightning-
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___
Lightning-dev mailing list
Lightning-dev@l
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 propose
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 propose a new
>> sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the previous
>
> I k
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 propose a new
> sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the previous
I know it seems kind of silly, but I think it's somewha
A technical point about SIGHASH_NOINPUT: It seems like a more general and
technically simpler to implement idea would be to have a boolean specifying
whether the inputs listed must be all of them (the way it works normally)
or a subset of everything. It feels like a similar boolean should be made
f
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 them. The current prop
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 p
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 if I'm actually criticising or playing
> The current proposal kind-of limits the potential damage by still
committing
> to the prevout amount, but it still seems a big risk for all the people
that
> reuse addresses, which seems to be just about everyone.
The typical address re-use doesn't apply here as this is a sighash flag that
would
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 if I'm actually criticising or playing devil's
advocate here, but either way I think cr
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 t
19 matches
Mail list logo
