📅 Original date posted:2016-09-23
📝 Original message:On Fri, Sep 23, 2016 at 10:20 PM, Luke Dashjr via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> In the innocent use case of this opcode, a double-spend has already occurred,
> and this should be a strict improvement. In the non-innocent abuse of this
> opcode, I don't see that it's any worse than simply double-spending.
There is a fungibility hit... right now, absent double spends (and
privacy issues), every coin you might get paid is equal.
With this script feature as described, you could get paid a coin which
has one of these in its recent past, pinning the block immediately
before it. A reorg long enough to remove that block-- due to an
attack, or an ordinary block race, or some kind of consensus glitch
(like we had in March 2013 or around the activation of BIP65)-- is
_guaranteed_ to invalidate those coins, even without any double spend.
If the scheme doesn't do as I suggest and prevent over-eager usage
(perhaps 100 is too much, I just decided to match coinbases); then it
should probably have a consensus enforced explicit "maximum survivable
reorg" that is traced along with the outputs, so that someone who
received exposed coins could handle it sensibly.
Just for plain engineering reasons, I still think it is important to
now allow overly short back references. If the reference has to be a
few blocks back we don't need to worry about short forks breaking
propagation, and simple mempool handling like purging all CBAH
transactions on a large reorg would work fine. It need not be so long
as to implicate Petertodd's concern that you could only use it where
it wouldn't matter. (Though I also disagree that a depth of 100
achieves that, consider persistent chain forks).
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 17:53:34
in reply to nevent1q…p63u
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetPublished at
2023-06-07 17:53:34Event JSON
{
"id": "8eab0d3e00898e10a2897f57ce3766f7046356d97f1ca5cf8c2e4542de09fba1",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686160414,
"kind": 1,
"tags": [
[
"e",
"d18826815090afbadc28ae1d0b7b8b63e39dcc4ada4cb48ae90cd951a4779d15",
"",
"root"
],
[
"e",
"038bc1b36f7d3aeb678fbad27d4cf70334317b2d439fec40c0c9537f20984465",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "📅 Original date posted:2016-09-23\n📝 Original message:On Fri, Sep 23, 2016 at 10:20 PM, Luke Dashjr via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e In the innocent use case of this opcode, a double-spend has already occurred,\n\u003e and this should be a strict improvement. In the non-innocent abuse of this\n\u003e opcode, I don't see that it's any worse than simply double-spending.\n\nThere is a fungibility hit... right now, absent double spends (and\nprivacy issues), every coin you might get paid is equal.\n\nWith this script feature as described, you could get paid a coin which\nhas one of these in its recent past, pinning the block immediately\nbefore it. A reorg long enough to remove that block-- due to an\nattack, or an ordinary block race, or some kind of consensus glitch\n(like we had in March 2013 or around the activation of BIP65)-- is\n_guaranteed_ to invalidate those coins, even without any double spend.\n\nIf the scheme doesn't do as I suggest and prevent over-eager usage\n(perhaps 100 is too much, I just decided to match coinbases); then it\nshould probably have a consensus enforced explicit \"maximum survivable\nreorg\" that is traced along with the outputs, so that someone who\nreceived exposed coins could handle it sensibly.\n\nJust for plain engineering reasons, I still think it is important to\nnow allow overly short back references. If the reference has to be a\nfew blocks back we don't need to worry about short forks breaking\npropagation, and simple mempool handling like purging all CBAH\ntransactions on a large reorg would work fine. It need not be so long\nas to implicate Petertodd's concern that you could only use it where\nit wouldn't matter. (Though I also disagree that a depth of 100\nachieves that, consider persistent chain forks).",
"sig": "f16a831e7d5fd0df3ca8ef0e6e021fe61a52a508f24df121727fe81a200f038282bba5ec9e286c5cb7beef02b7964c3b63db7fb38f630bb31a56fc7f29cf85f9"
}