š
Original date posted:2014-01-21
š Original message:On Wed, 15 Jan 2014 17:32:31 -0800, Gregory Maxwell <gmaxwell at gmail.com>
wrote:
> 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.
I might be misunderstanding, but I think prefix length must be specified
in the reusable address, however I agree the prefix actually published to
the blockchain should be constant length.
> 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.
Let's say the payee's reusable address is '<version> <prefix> <Q1> <Q2>
...', where <prefix> is 2 bytes. Without any length indicator. What's the
payer going to put on the blockchain? How would they know what the 'rest
of the space' is? They would have to put the whole <prefix> verbatim into
the OP_RETURN without knowing how many bits of <prefix> the payee actually
wants to see there.
If instead, the address is '<version> <prefix> <prefixLen> <Q1> <Q2> ...'
where <prefix> is 2 bytes, and <prefixLen> is 1 byte, representing number
of bits of prefix that should be fixed.
Then payer will know how much of <prefix> from the address should be taken
verbatim, and the rest of the two bytes would be replaced with random
data, and exactly two bytes would be put in the OP_RETURN.
If <prefixLen> was zero, the 2 byte prefix in the reusable address must be
ignored, and an entirely random 2 byte prefix would be put into the
OP_RETURN.
I'm a bit worried about broken implementations copying the <prefix> from
the reusable address into OP_RETURN when <prefixLen> is 0, and ending up
basically identifying the payee. That's the only reason I can think of to
make '<prefix> <prefixLen>' optional in the reusable address, to prevent
the opportunity to screw it up. You would *still* put a 2-byte random
prefix in the OP_RETURN, even if the fields weren't in the address at all.
It's just a minor concern though.
Jeremy Spilman [ARCHIVE] /
npub10eā¦jc727
2023-06-07 15:11:59
in reply to nevent1qā¦hx2w
Author Public Key
npub10etkvm8l0jr0jsgdx02dxnhnu5g989dnca90guj5rklwkaplnh3sgjc727Seen on
wss://relay.noswhere.comPublished at
2023-06-07 15:11:59Event JSON
{
"id": "0b9448fc2f5045d6b51b59def0e74e74abfdee6454e03b820b1e8a361c3a21d1",
"pubkey": "7e57666cff7c86f9410d33d4d34ef3e5105395b3c74af472541dbeeb743f9de3",
"created_at": 1686150719,
"kind": 1,
"tags": [
[
"e",
"eca224fd79062c438f672eeb721d19eecb21242447f685d7841ab4222dcc04f4",
"",
"root"
],
[
"e",
"bdeea047e67a39186618e2fc7e89c1d954c8e2985fa69d705e48d9c2a99ee931",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "š
Original date posted:2014-01-21\nš Original message:On Wed, 15 Jan 2014 17:32:31 -0800, Gregory Maxwell \u003cgmaxwell at gmail.com\u003e \nwrote:\n\u003e I'd point out that regardless of how long the desired prefix is, the\n\u003e encoded prefix should probably always be constant length in all\n\u003e reusable addresses.\n\nI might be misunderstanding, but I think prefix length must be specified \nin the reusable address, however I agree the prefix actually published to \nthe blockchain should be constant length.\n\n\u003e If you don't want a particular prefix then the\n\u003e sender should just pick random data for the rest of the space. There\n\u003e is no need to publish any additional distinguishing data in the form\n\u003e of how long the prefix is.\n\nLet's say the payee's reusable address is '\u003cversion\u003e \u003cprefix\u003e \u003cQ1\u003e \u003cQ2\u003e \n...', where \u003cprefix\u003e is 2 bytes. Without any length indicator. What's the \npayer going to put on the blockchain? How would they know what the 'rest \nof the space' is? They would have to put the whole \u003cprefix\u003e verbatim into \nthe OP_RETURN without knowing how many bits of \u003cprefix\u003e the payee actually \nwants to see there.\n\nIf instead, the address is '\u003cversion\u003e \u003cprefix\u003e \u003cprefixLen\u003e \u003cQ1\u003e \u003cQ2\u003e ...' \nwhere \u003cprefix\u003e is 2 bytes, and \u003cprefixLen\u003e is 1 byte, representing number \nof bits of prefix that should be fixed.\n\nThen payer will know how much of \u003cprefix\u003e from the address should be taken \nverbatim, and the rest of the two bytes would be replaced with random \ndata, and exactly two bytes would be put in the OP_RETURN.\n\nIf \u003cprefixLen\u003e was zero, the 2 byte prefix in the reusable address must be \nignored, and an entirely random 2 byte prefix would be put into the \nOP_RETURN.\n\nI'm a bit worried about broken implementations copying the \u003cprefix\u003e from \nthe reusable address into OP_RETURN when \u003cprefixLen\u003e is 0, and ending up \nbasically identifying the payee. That's the only reason I can think of to \nmake '\u003cprefix\u003e \u003cprefixLen\u003e' optional in the reusable address, to prevent \nthe opportunity to screw it up. You would *still* put a 2-byte random \nprefix in the OP_RETURN, even if the fields weren't in the address at all. \nIt's just a minor concern though.",
"sig": "c125bc736714e9d313bbf5e7cbd189d08bd6e91e405599d719e1781b6aeecff800750ddd8c6c768d9e95d4b238a9b7484cda9e469a6c51291b9abc8bcca69657"
}