📅 Original date posted:2014-01-15
📝 Original message:On Wed, Jan 15, 2014 at 5:02 PM, Jeremy Spilman <jeremy at taplink.co> wrote:
> Choosing how many bits to put in the prefix may be difficult, particularly
> if transaction load changes dramatically over time. 0 or 1 bits may be
> just fine for a single user running their own node, whereas a central
> service might want 4 or 5 bits to keep their computation costs scalable.
Ignoring prefixes the cost for each reusable address is only a small
percentage of the full node cost (rational: each transaction has one
or more ECDSA signatures, and the derivation is no more expensive), so
I would only expect computation to be an issue for large centralized
services. (non-full nodes suffer more from just the bandwidth impact).
I'd point out that regardless of how long the desired prefix is, the
encoded prefix should probably always be constant length in all
reusable addresses. If you don't want a particular prefix then the
sender should just pick random data for the rest of the space. There
is no need to publish any additional distinguishing data in the form
of how long the prefix is.
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 15:11:58
in reply to nevent1q…dadp
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetSeen on
wss://relay.noswhere.comPublished at
2023-06-07 15:11:58Event JSON
{
"id": "bf5f464d949a4aa1296c2580ac2a1ffa323113fbe39cbdf2f5d1cf40a3def6b5",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686150718,
"kind": 1,
"tags": [
[
"e",
"eca224fd79062c438f672eeb721d19eecb21242447f685d7841ab4222dcc04f4",
"",
"root"
],
[
"e",
"99fcf91e16a2dca8770a14964460c8bba517909fca658ddd39bb645beb774a92",
"",
"reply"
],
[
"p",
"7e57666cff7c86f9410d33d4d34ef3e5105395b3c74af472541dbeeb743f9de3"
]
],
"content": "📅 Original date posted:2014-01-15\n📝 Original message:On Wed, Jan 15, 2014 at 5:02 PM, Jeremy Spilman \u003cjeremy at taplink.co\u003e wrote:\n\u003e Choosing how many bits to put in the prefix may be difficult, particularly\n\u003e if transaction load changes dramatically over time. 0 or 1 bits may be\n\u003e just fine for a single user running their own node, whereas a central\n\u003e service might want 4 or 5 bits to keep their computation costs scalable.\n\nIgnoring prefixes the cost for each reusable address is only a small\npercentage of the full node cost (rational: each transaction has one\nor more ECDSA signatures, and the derivation is no more expensive), so\nI would only expect computation to be an issue for large centralized\nservices. (non-full nodes suffer more from just the bandwidth impact).\n\nI'd point out that regardless of how long the desired prefix is, the\nencoded prefix should probably always be constant length in all\nreusable addresses. If you don't want a particular prefix then the\nsender should just pick random data for the rest of the space. There\nis no need to publish any additional distinguishing data in the form\nof how long the prefix is.",
"sig": "8af06735df5d805775e415e22fd72e23bd7312b99fdcffb8d11f9a171ac24bb524712331e64534c9061a666313da67be86058790bcb16142145ba0c710ac4333"
}