📅 Original date posted:2016-02-26
📝 Original message:Hi Bryan,
On Thu, Feb 25, 2016 at 07:34:24PM -0600, Bryan Bishop wrote:
> Well if you are bothering to draft up a BIP about that SIGHASH flag,
> then perhaps also consider some other SIGHASH flag types as well while
> you are at it?
I'll take a look at those proposals when drafting the BIP. I think for
LN, there is a single clean way to achieve outsourcability, but may be
compatible with other arrangements. I'm somewhat averse to proposing too
much flexibility before there's clear use-cases, though. However, if
others do have uses/examples for other sighash flags, I'd be very
interested while drafting this BIP!
> FWIW there was some concern about replay using SIGHAHS_NOINPUT or something:
> http://gnusha.org/bitcoin-wizards/2015-04-07.log
Yeah, I think the nice thing about SegWit is that you resolve
malleability without worrying about replay attacks in the event of key
reuse. That's why I think it's only safe to do this new sighash type
inside segwit itself -- if you only wanted protection against
malleability you'd use segwit, and not touch this new sighash type
(you'd only use the new sighash flag if you actually need its features).
--
Joseph Poon
Joseph Poon [ARCHIVE] /
npub1ej…p9cq8
2023-06-07 17:49:18
in reply to nevent1q…8ts5
Author Public Key
npub1ej6vep7y2km5l6awukffelg8yeppkth2vjkjk9jypd5w336rxggs3p9cq8Published at
2023-06-07 17:49:18Event JSON
{
"id": "a9681cd5dd9338520f689f10213e8e98c98e05081bcea81e28910013cd2c5fd4",
"pubkey": "ccb4cc87c455b74febaee5929cfd0726421b2eea64ad2b16440b68e8c7433211",
"created_at": 1686160158,
"kind": 1,
"tags": [
[
"e",
"02573c72a5c10170b07062b4c65addc713ac4f80993cb36ed0c5880b6d715a41",
"",
"root"
],
[
"e",
"77fb90400595372e4040eaca142cc101d276366dcae98a9825040ef77fe5d5d3",
"",
"reply"
],
[
"p",
"62ddcb547224b421822b62845fb1bbd77c838b924bd022814cfcbe25b7a07475"
]
],
"content": "📅 Original date posted:2016-02-26\n📝 Original message:Hi Bryan,\n\nOn Thu, Feb 25, 2016 at 07:34:24PM -0600, Bryan Bishop wrote:\n\u003e Well if you are bothering to draft up a BIP about that SIGHASH flag,\n\u003e then perhaps also consider some other SIGHASH flag types as well while\n\u003e you are at it?\n\nI'll take a look at those proposals when drafting the BIP. I think for\nLN, there is a single clean way to achieve outsourcability, but may be\ncompatible with other arrangements. I'm somewhat averse to proposing too\nmuch flexibility before there's clear use-cases, though. However, if\nothers do have uses/examples for other sighash flags, I'd be very\ninterested while drafting this BIP!\n\n\u003e FWIW there was some concern about replay using SIGHAHS_NOINPUT or something:\n\u003e http://gnusha.org/bitcoin-wizards/2015-04-07.log\n\nYeah, I think the nice thing about SegWit is that you resolve\nmalleability without worrying about replay attacks in the event of key\nreuse. That's why I think it's only safe to do this new sighash type\ninside segwit itself -- if you only wanted protection against\nmalleability you'd use segwit, and not touch this new sighash type\n(you'd only use the new sighash flag if you actually need its features).\n\n-- \nJoseph Poon",
"sig": "1942657ae86cd423297bffefe8abe22b8da27287b92227c84aadda1581fc76cd56a49e4890222142087e82aa4ac840aa56712eb4b26721a2bffde72541fd1996"
}