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
Hi Clark,
Thanks for the feedback. I was somewhat coming to the same conclusion as
yourself having had a few days to think on it.
I am going to support SLIP-0032 for the serialization format of extended keys
as I believe this adds value in terms of additional validation when extended
public k
Paul,
The current BIP-49 / 84 use the purpose field of the derivation path to specify
the address format.
I think sticking with the one-BIP-one-format method works. Otherwise, you
would need to modify this proposed BIP each time a new format comes along.
In that case, existing wallets that claim
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