Peter Todd [ARCHIVE] on Nostr: š Original date posted:2014-01-24 š Original message:On Mon, Jan 20, 2014 at ...
š
Original date posted:2014-01-24
š Original message:On Mon, Jan 20, 2014 at 08:00:05PM -0800, Jeremy Spilman wrote:
> 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.
Something to keep in mind is that it's quite likely that the indexes
available will be over H(scriptPubKey). There's really good engineering
reasons for doing this: you need to be able to create succinct proofs of
fraud in indexes, miner committed and otherwise, and the only way they
are succinct is if you limit the length. Hashes naturally do that
because it's so expensive to generate partial collisions.
If you don't do this on the other hand now you have a situation where
the usual case - max 16 level deep tree - and worst case - hundreds or
even thousands of levels deep - are vastly different. That's hard to
test for and likely to reveal implementation-specific limits in nasty
ways.
Anyway, grinding nonces isn't much of a burden given it's fast hash
functions. The prefixes in question are fairly small and will be small
for the forseeable future. As I said elsewhere in this thread, even
Javascript has performance that's perfectly adequate for the task.
--
'peter'[:-1]@petertodd.org
00000000000000003590a8a20ec9ff5b1c1af3f046a1f62dc1ac9a464721fd8f
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 685 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140124/eb99c0a2/attachment.sig>;
š Original message:On Mon, Jan 20, 2014 at 08:00:05PM -0800, Jeremy Spilman wrote:
> 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.
Something to keep in mind is that it's quite likely that the indexes
available will be over H(scriptPubKey). There's really good engineering
reasons for doing this: you need to be able to create succinct proofs of
fraud in indexes, miner committed and otherwise, and the only way they
are succinct is if you limit the length. Hashes naturally do that
because it's so expensive to generate partial collisions.
If you don't do this on the other hand now you have a situation where
the usual case - max 16 level deep tree - and worst case - hundreds or
even thousands of levels deep - are vastly different. That's hard to
test for and likely to reveal implementation-specific limits in nasty
ways.
Anyway, grinding nonces isn't much of a burden given it's fast hash
functions. The prefixes in question are fairly small and will be small
for the forseeable future. As I said elsewhere in this thread, even
Javascript has performance that's perfectly adequate for the task.
--
'peter'[:-1]@petertodd.org
00000000000000003590a8a20ec9ff5b1c1af3f046a1f62dc1ac9a464721fd8f
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 685 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140124/eb99c0a2/attachment.sig>;