📅 Original date posted:2015-03-25
📝 Original message:On Wed, Mar 25, 2015 at 6:44 PM, Tom Harding <tomh at thinlink.com> wrote:
> Is this assuming payment protocol? A major benefit of address
> expiration, if it works, would be that it works without requiring
> payment protocol.
Not at all.
> Are you suggesting there is no implementation of address expiration that
> wouldn't allow the string to be trivially changed by the sender?
The sender is always able to intentionally hide their payment under a
rock-- There is no encoding that can prevent that.
The defense against that is to not accept payments not made according
to the payees specification.
> I don't understand, explanation would be appreciated.
To reject reused scriptPubKeys you must remember past scriptPubkeys in
order to test against them.
For illustration purposes imagine a bitcoin system where there is only
a single base unit available for trade.
Verification of that chain requires O(1) storage (the identity of the
current chain tip, and the identity of the spendable coin.).
Verification with duplicate elimination requires O(N) storage (with N
being the length of the history), since you need to track all the
duplicates to reject.
(The same is true for actual Bitcoin as well, though the constant
factors make the difference somewhat less stark.)
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 15:32:13
in reply to nevent1q…0vth
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetSeen on
wss://relay.nostr.bandPublished at
2023-06-07 15:32:13Event JSON
{
"id": "f83d2a9f014d57762d85a3f889c59a4e123f0912a34790929010415a951156e8",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686151933,
"kind": 1,
"tags": [
[
"e",
"13ba2dac7eec5154e8f99682c168a8cede79e5ef5e0b1fe726762657ed73749d",
"",
"root"
],
[
"e",
"2644a0d19e003763164b0574325a66f63855b05e2c4b549d64865ba16c3d5ce7",
"",
"reply"
],
[
"p",
"dc329a02c970aabf03b87185ef51c86afe4586fe3a148508af898af3fabc56a3"
]
],
"content": "📅 Original date posted:2015-03-25\n📝 Original message:On Wed, Mar 25, 2015 at 6:44 PM, Tom Harding \u003ctomh at thinlink.com\u003e wrote:\n\u003e Is this assuming payment protocol? A major benefit of address\n\u003e expiration, if it works, would be that it works without requiring\n\u003e payment protocol.\n\nNot at all.\n\n\u003e Are you suggesting there is no implementation of address expiration that\n\u003e wouldn't allow the string to be trivially changed by the sender?\n\nThe sender is always able to intentionally hide their payment under a\nrock-- There is no encoding that can prevent that.\n\nThe defense against that is to not accept payments not made according\nto the payees specification.\n\n\u003e I don't understand, explanation would be appreciated.\n\nTo reject reused scriptPubKeys you must remember past scriptPubkeys in\norder to test against them.\n\nFor illustration purposes imagine a bitcoin system where there is only\na single base unit available for trade.\n\nVerification of that chain requires O(1) storage (the identity of the\ncurrent chain tip, and the identity of the spendable coin.).\nVerification with duplicate elimination requires O(N) storage (with N\nbeing the length of the history), since you need to track all the\nduplicates to reject.\n\n(The same is true for actual Bitcoin as well, though the constant\nfactors make the difference somewhat less stark.)",
"sig": "c7fae3e12aea8c4ddfd9dc9fa7d901c27643435355c128dd8640341a6af162f743e1292b5fb2fbdc3b66f8c93b03dbc0eff8ecd27f881870686bec80d9d6cdc3"
}