Oh, I missed that that's still the case with NOINPUT - thanks for pointing it
out. In that case there's no reason to sign the other inputs' sequence and
that's even better because the current NOINPUT proposal already enables
taprootifiability of eltoo unilateral closings.
On 9/26/18 7:45 PM, Johns
In BIP143, the nSequence of the same input is always signed, with any hashtype.
Why do you need to sign the sequence of other inputs?
> On 26 Sep 2018, at 5:36 PM, Jonas Nick via bitcoin-dev
> wrote:
>
>> At the risk of bikeshedding, shouldn't NOINPUT also zero out the
>> hashSequence so that
> At the risk of bikeshedding, shouldn't NOINPUT also zero out the
> hashSequence so that its behaviour is consistent with ANYONECANPAY?
There is a good reason for not doing that. If NOINPUT would sign the
hashSequence then it would be possible to get rid of OP_CSV in eltoo update
scripts. As a re
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.
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
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
Olaoluwa Osuntokun writes:
> Super stoked to see that no_input has been resurrected!!! I actually
> implemented a variant back in 2015 when Tadge first described the
> approach to me for both btcd [1], and bitcoind [2]. The version being
> proposed is _slightly_ differ though, as the initial versi
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
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
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
Super stoked to see that no_input has been resurrected!!! I actually
implemented a variant back in 2015 when Tadge first described the approach
to
me for both btcd [1], and bitcoind [2]. The version being proposed is
_slightly_ differ though, as the initial version I implemented still
committed
to
Given the general enthusiasm, and lack of major criticism, for the
`SIGHASH_NOINPUT` proposal, I'd like to formally ask the BBEs (benevolent
BIP editors) to be assigned a BIP number. I have hacked together a
simple implementation of the hashing implementation in Bitcoin Core [1]
though I think it's
Good morning Christian,
> ZmnSCPxj zmnsc...@protonmail.com writes:
>
> > It seems to me, that `SIGHASH_NOINPUT` may help make some protocol
> >
> > integrate better with existing wallets.
>
> Depends on which end of a transaction the existing wallet is: existing
>
> wallets will refuse to sig
Good morning Christian and list,
It seems to me, that `SIGHASH_NOINPUT` may help make some protocol integrate
better with existing wallets.
I remember vaguely that `SIGHASH_NOINPUT` was also mentioned before in LN
discussions, when the issue of transaction malleation was considered (before
Seg
ZmnSCPxj writes:
> It seems to me, that `SIGHASH_NOINPUT` may help make some protocol
> integrate better with existing wallets.
Depends on which end of a transaction the existing wallet is: existing
wallets will refuse to sign a transaction with an unknown sighash flag,
but if the wallet is creat
Russell O'Connor writes:
> At the risk of bikeshedding, shouldn't NOINPUT also zero out the
> hashSequence so that its behaviour is consistent with ANYONECANPAY?
Good catch, must've missed that somehow. I'll amend the BIP accordingly.
___
bitcoin-dev ma
At the risk of bikeshedding, shouldn't NOINPUT also zero out the
hashSequence so that its behaviour is consistent with ANYONECANPAY?
On Mon, Apr 30, 2018 at 12:29 PM, Christian Decker via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi all,
>
> I'd like to pick up the discussion
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
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
output. This was previously mentioned on the list by Joseph Poon [1], but was
never formally proposed, so I wrote a proposal [2].
We hav
23 matches
Mail list logo
