📅 Original date posted:2016-02-25
📝 Original message:On Fri, Feb 26, 2016 at 1:07 AM, Joseph Poon via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I'm interested in input and in the level of receptiveness to this. If
> there is interest, I'll write up a draft BIP in the next couple days.
The design of segwit was carefully constructed to make it maximally
easy and safe to soft-fork in future script enhancements after its
deployment with the specific goal of avoiding indefinite delays in its
deployment from inevitable scope creep from additional things that are
"easy" to deploy as part of segwit. I think to be successful we must
be absolutely ruthless about changes that go in there beyond the
absolute minimum needed for the safe deployment of segwit... so I
think this should probably be constructed as a new segwit script type,
and not a base feature.
The exact construction you're thinking of there isn't clear to me...
one thing that comes to mind is that I think it is imperative that we
do not deploy a without-inputs SIGHASH flag without also deploying at
least a fee-committing sighash-all. The reason for this is that if
hardware wallets are forced to continue transferring input
transactions to check fees or to use without-inputs, they may choose
the latter and leave the users needlessly exposed to replay attacks.
When you do write a BIP for this its imperative that the vulnerability
to replay is called out in bold blinking flaming text, along with the
necessary description of how to use it safely. The fact that without
input commitments transactions are replayable is highly surprising to
many developers... Personally, I'd even go so far as to name the flag
SIGHASH_REPLAY_VULNERABLE. :)
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 17:49:16
in reply to nevent1q…e7jd
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetPublished at
2023-06-07 17:49:16Event JSON
{
"id": "db528bd35aa3beaf2c08d8023c7bde481aa83d29bdd45710cd591ee1c94cc0f8",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686160156,
"kind": 1,
"tags": [
[
"e",
"02573c72a5c10170b07062b4c65addc713ac4f80993cb36ed0c5880b6d715a41",
"",
"root"
],
[
"e",
"1f581a54d43c333843faee865a6a4c70c7e2182ba4d785d536faf3631799cb8a",
"",
"reply"
],
[
"p",
"ccb4cc87c455b74febaee5929cfd0726421b2eea64ad2b16440b68e8c7433211"
]
],
"content": "📅 Original date posted:2016-02-25\n📝 Original message:On Fri, Feb 26, 2016 at 1:07 AM, Joseph Poon via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e I'm interested in input and in the level of receptiveness to this. If\n\u003e there is interest, I'll write up a draft BIP in the next couple days.\n\nThe design of segwit was carefully constructed to make it maximally\neasy and safe to soft-fork in future script enhancements after its\ndeployment with the specific goal of avoiding indefinite delays in its\ndeployment from inevitable scope creep from additional things that are\n\"easy\" to deploy as part of segwit. I think to be successful we must\nbe absolutely ruthless about changes that go in there beyond the\nabsolute minimum needed for the safe deployment of segwit... so I\nthink this should probably be constructed as a new segwit script type,\nand not a base feature.\n\nThe exact construction you're thinking of there isn't clear to me...\none thing that comes to mind is that I think it is imperative that we\ndo not deploy a without-inputs SIGHASH flag without also deploying at\nleast a fee-committing sighash-all. The reason for this is that if\nhardware wallets are forced to continue transferring input\ntransactions to check fees or to use without-inputs, they may choose\nthe latter and leave the users needlessly exposed to replay attacks.\n\nWhen you do write a BIP for this its imperative that the vulnerability\nto replay is called out in bold blinking flaming text, along with the\nnecessary description of how to use it safely. The fact that without\ninput commitments transactions are replayable is highly surprising to\nmany developers... Personally, I'd even go so far as to name the flag\nSIGHASH_REPLAY_VULNERABLE. :)",
"sig": "b4a219897864ec873e2ef42ee31031b8b163aab822e5f386d6834f697fcd8072e1fa6c28e8d5703dd3f6113919c479ab7bf3c9e4e96b110dc03d2be4d5825d12"
}