Good morning Ethan,
> To avoid derailing the NO_INPUT conversation, I have changed the
> subject to OP_CAT.
>
> Responding to:
> """
>
> - `SIGHASH` flags attached to signatures are a misdesign, sadly
> retained from the original BitCoin 0.1.0 Alpha for Windows design, on
> par with:
>
I hope you are having an great afternoon ZmnSCPxj,
You make an excellent point!
I had thought about doing the following to tag nodes
|| means OP_CAT
`node = SHA256(type||SHA256(data))`
so a subnode would be
`subnode1 = SHA256(1||SHA256(subnode2||subnode3))`
and a leaf node would be
`leafnode =
To avoid derailing the NO_INPUT conversation, I have changed the
subject to OP_CAT.
Responding to:
"""
* `SIGHASH` flags attached to signatures are a misdesign, sadly
retained from the original BitCoin 0.1.0 Alpha for Windows design, on
par with:
[..]
* `OP_CAT` and `OP_MULT` and `OP_ADD` and
Anthony Towns writes:
> On Mon, Sep 30, 2019 at 03:23:56PM +0200, Christian Decker via bitcoin-dev
> wrote:
>> With the recently renewed interest in eltoo, a proof-of-concept
>> implementation
>> [1], and the discussions regarding clean abstractions for off-chain protocols
>> [2,3], I thought
Chris Stewart writes:
> I do have some concerns about SIGHASH_NOINPUT, mainly that it does
> introduce another footgun into the bitcoin protocol with address reuse.
> It's common practice for bitcoin businesses to re-use addresses. Many
> exchanges [1] reuse addresses for cold storage with very
Chris Stewart writes:
>> I don't find too compelling the potential problem of a 'bad wallet
> designer', whether lazy or dogmatic, misusing noinput. I think there are
> simpler ways to cut corners and there will always be plenty of good wallet
> options people can choose.
>
> In my original
