Streams redesign #1631

New Issue

2020-05-28T04:43:53+02:00

PeterSurda commented

2020-05-28 04:43:53 +02:00

(Migrated from github.com)

The current streams design, even though not fully implemented, has in my opinion a significant drawback: in order to benefit from scaling adjustments, users have to create new addresses and abandon new ones. This proposal changes how an address' position in the binary tree is determined. The current design assigns an extra variable to determine this, and the position is then fixed. Instead, I propose that the location be determined as a combination of a global variable recommended depth, and a path derived starting from the least significant bit of the address (or pubkey).

Since #1612 eliminates pubkey/getpubkey objects, the sender always knows the recipients' public key and can thus calculate the path. The recommended depth can be determined by a variety of methods, at the beginning it can be centralised with a publicly available process so that it can be audited. Nodes will then reject objects whose streams don't have at least the recommended depth.

The objects, and nodes will still contain streams as in the current protocol, so their design doesn't need to change. Perhaps the interpretation needs to be adjusted. E.g. for node, the stream will also mean the minimum depth they require and a calculation needs to be performed if the arriving object is "under" the specified stream. It should be possible to do this efficiently using bit-wise operations. Only addresses need to be changed not to contain streams. Since #1612 needs to change the address structure anyway, the two changes can be implemented together.

The main advantages are that it is possible to scale easier on the fly, and that the changes to current design are small. I think also implementing it is easier. While the signalling of depth has potential weaknesses, the legacy design isn't better: there also isn't an agreed upon method for signalling when people should start generating addresses in new streams.

The current streams design, even though not fully implemented, has in my opinion a significant drawback: in order to benefit from scaling adjustments, users have to create new addresses and abandon new ones. This proposal changes how an address' position in the binary tree is determined. The current design assigns an extra variable to determine this, and the position is then fixed. Instead, I propose that the location be determined as a combination of a global variable recommended depth, and a path derived starting from the least significant bit of the address (or pubkey). Since #1612 eliminates pubkey/getpubkey objects, the sender always knows the recipients' public key and can thus calculate the path. The recommended depth can be determined by a variety of methods, at the beginning it can be centralised with a publicly available process so that it can be audited. Nodes will then reject objects whose streams don't have at least the recommended depth. The objects, and nodes will still contain streams as in the current protocol, so their design doesn't need to change. Perhaps the interpretation needs to be adjusted. E.g. for node, the stream will also mean the minimum depth they require and a calculation needs to be performed if the arriving object is "under" the specified stream. It should be possible to do this efficiently using bit-wise operations. Only addresses need to be changed not to contain streams. Since #1612 needs to change the address structure anyway, the two changes can be implemented together. The main advantages are that it is possible to scale easier on the fly, and that the changes to current design are small. I think also implementing it is easier. While the signalling of depth has potential weaknesses, the legacy design isn't better: there also isn't an agreed upon method for signalling when people should start generating addresses in new streams.

This repo is archived. You cannot comment on issues.