Pay to coordinates - idea/discussion

Olà

based on :

Imagine : :star2:

let say that the database is maintaining an index

when a new identity is joining the WOT, it increment an index ( <= represented by a number wich refer in the original algorithm as the " distance " or " z value" … )

  • what follow can be seen like a SQL request : « select pubkey from wot order by entry_date/timestamp »

assume we got such a request that give us :

0 ‹ 12JDJibbgZPRfD6Hoecg8rQRvCR5VYrMnqzfhQYmAr3k ›
1 ‹ 13XfrqY92tTCDbtu2jFAHsgNbZ9Ne2r5Ts1VGhSCrvUb ›
2 ‹ 13fn6X3XWVgshHTgS8beZMo9XiyScx6MB6yPsBB5ZBia ›

2108 ‹ yqBbrgDm5SLQj6rgPup6Nc1AUZTetERYBuUtbrm53Pn ›
2109 ‹ zV3yXy5iC68ksE93AGp6stCoczaSfNFE2Hac7h1q7ZA ›
4294967295 ‹ HD3Syggysdoe7c8UXwgTmxzvKJ7io4Qxrr5jSrDUnfjU ›

associated index through a 32 bits number (unsigned int) can be computed to make 2D point like that :

0 ‹ 12JDJibbgZPRfD6Hoecg8rQRvCR5VYrMnqzfhQYmAr3k › [0, 0]
1 ‹ 13XfrqY92tTCDbtu2jFAHsgNbZ9Ne2r5Ts1VGhSCrvUb › [1, 0]
2 ‹ 13fn6X3XWVgshHTgS8beZMo9XiyScx6MB6yPsBB5ZBia › [0, 1]

2108 ‹ yqBbrgDm5SLQj6rgPup6Nc1AUZTetERYBuUtbrm53Pn › [6, 38]
2109 ‹ zV3yXy5iC68ksE93AGp6stCoczaSfNFE2Hac7h1q7ZA › [7, 38]
4294967295 ‹ HD3Syggysdoe7c8UXwgTmxzvKJ7io4Qxrr5jSrDUnfjU › [65535 , 65535]

in that way users can do transaction like :

" send 10 Junes to [6, 38] " <=> where [6, 38] 2D coordinate correspond to index 2108, mapped to public key => yqBbrgDm5SLQj6rgPup6Nc1AUZTetERYBuUtbrm53Pn

" send 30 Junes to [0, 1] " <=> 13fn6X3XWVgshHTgS8beZMo9XiyScx6MB6yPsBB5ZBia
etc…

  1. one point about the uint32 maximum number (inclusive) is => 4294967295
    wich let index 4 294 967 295 peoples without problem.

the 4 294 967 296 n’th WOT member will break down the feature since the index with 32 bits when converted will overlap,
meaning that his coordinate point will give => [0, 0] => allready mapped, so 2 public key will match…this is the limit…

  1. but if we either want to step through,
    encoding/using a 64 bits number (unsigned long long) will give us coordinate point like :

0 ‹ 12JDJibbgZPRfD6Hoecg8rQRvCR5VYrMnqzfhQYmAr3k › [0, 0]
1 ‹ 13XfrqY92tTCDbtu2jFAHsgNbZ9Ne2r5Ts1VGhSCrvUb › [1, 0]
2 ‹ 13fn6X3XWVgshHTgS8beZMo9XiyScx6MB6yPsBB5ZBia › [0, 1]

2108 ‹ yqBbrgDm5SLQj6rgPup6Nc1AUZTetERYBuUtbrm53Pn › [6, 38]
2109 ‹ zV3yXy5iC68ksE93AGp6stCoczaSfNFE2Hac7h1q7ZA › [7, 38]
4294967295 ‹ HD3Syggysdoe7c8UXwgTmxzvKJ7io4Qxrr5jSrDUnfjU › [65535 , 65535]
4294967296 ‹ ePs5xpo1rMQgvrKrthYXSLHMawKTNebqFnUqifW5P6v › [65536 , 0]
18446744073709551615, ‹ QcwFU8YbZRtvLxLGHqznmEbGFvU9YUETEQc6cFmRRg8 › [ 4294967295 , 4294967295 ]

meaning a maximum (inclusive) of … 18 446 744 073 709 551 615 members before overlapping.


Resume :spiral_notepad:

Possibility to pay someone who has been member knowing his coordinates

can be a new opcode integrated along SIG/XHX/CSV/CLTV

call that P2C for " pay to 2 coordinate ",

it take 2 parameters => the x,y coordinates of the point in 2d space

which can be done in that way :

P2C(0,0)

P2C(65535,65535) [max when index 32 bits]
or
P2C(4294967295,4294967295) [max when index 64 bits]

where based on example above :

P2C(0,0) <=> pay to 12JDJibbgZPRfD6Hoecg8rQRvCR5VYrMnqzfhQYmAr3k

P2C(65535,65535) <=> pay to HD3Syggysdoe7c8UXwgTmxzvKJ7io4Qxrr5jSrDUnfjU

& so on & so forth…

Constraint :

maintaining the index

and not remap associated public key with the coordinate point.

The first WOT member take the first index,

he will have the coordinate [0,0] for all the life of the system,

even if he loose is " WOT member status " and / or gain later this state,

he will forever be able to receive funds when people make transaction which refer to coordinate [0,0] <=> P2C(0,0)

Minimizing infos to store in the database for the transaction document:

database grow up…

count the opcode string : P2C / SIG and parenthesis

such a string « P2C(4294967295,4294967295) » take less space than « SIG(QcwFU8YbZRtvLxLGHqznmEbGFvU9YUETEQc6cFmRRg8) »

P2C(0,0) => 8 characters (minimum)
P2C(65535,65535) => 16 characters (maximum) [32 bits index ]
P2C(4294967295,4294967295) => 26 characters (maximum) [64 bits index]

with a base58 encoded string, a range of [48, 49] characters
SIG(QcwFU8YbZRtvLxLGHqznmEbGFvU9YUETEQc6cFmRRg8) => min 48 characters

Personnal opinion :lips:

i think it could be more « user friendly » to deal with tuple of numbers instead of 43/44 characters.

  • more simple to memorize & share with others in « everyday life », just communicate coordinates

Pay to « 7, 38 » instead of Pay to « zV3FXa9…blabla… »

in a way like pin [phone/credit card] to remember… avoiding to scan QRCode (for simple numbers)… or searching uid/public key…

  • in a case where people make errors with the coordinates, let say [1222, 0] instead of [1223, 0]

the money will be transfert to an account wich :

  1. was allready used by someone ( by a Wot member )

  2. or potentialy associated to a futur incoming.

it present intuitively « less lost » of money in the system than a base58 string mistake…

What can be done :brain:

It can serve to build 3D point coordinates so we can imagine something like

P3C(0,0,0)

with a max index/distance of … 281 474 976 710 655 inside a 64bits number wihere each points (x,y,z) are 32 bits numbers

give us a P3C(65535,65535,65535) , meaning 22 characters for the string in the database point of view

based on example above :

0 : P3C(0,0,0) <=> pay to 12JDJibbgZPRfD6Hoecg8rQRvCR5VYrMnqzfhQYmAr3k

2108 : P3C(2,2,11) <=> pay to yqBbrgDm5SLQj6rgPup6Nc1AUZTetERYBuUtbrm53Pn

2109 : P3C(3,2,11) <=> pay to zV3yXy5iC68ksE93AGp6stCoczaSfNFE2Hac7h1q7ZA

4294967295 : P3C(2047,2047,1023) <=> pay to HD3Syggysdoe7c8UXwgTmxzvKJ7io4Qxrr5jSrDUnfjU

4294967296 : P3C(0,0,1024) <=> pay to ePs5xpo1rMQgvrKrthYXSLHMawKTNebqFnUqifW5P6v

281474976710655: P3C(65535,65535,65535) <=> pay to…XXX

281474976710656: too big…


Huho

well, hoping that this is sufficiently clear at 1st reading,


i will push some C code to demonstrate conversions (encoding/decoding) functions if you want/think it can help/believe it could be a good idea

:slight_smile: