Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

standard "global addresses" #14

Open
Alrighttt opened this issue Aug 6, 2020 · 5 comments
Open

standard "global addresses" #14

Alrighttt opened this issue Aug 6, 2020 · 5 comments

Comments

@Alrighttt
Copy link
Member

We need to decide on a standard model for how pyCC will handle global(private key is publicly known) addresses.

I have made a PoC for how we might do this at:
https://github.com/Alrighttt/pycc-1/blob/b20bd5eae2f307ea07697655708ce1eba8bd2b85/pycc/examples/faucet.py#L76

This method gives each eval code an arbitrary amount of unique global addresses, each user-defined.

As an example of how this works, a user creating a faucet plan would provide an arbitrary string. This arbitrary string is then hashed and the hash is used as the raw ecdsa privkey for the global keypair. This gives us 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4140 unique global addresses per eval code. In the very rare case of the string's hash being greater than FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4140, we can detect this and simply hash the hash.

From a user perspective(this will not be unique to a faucet CC)....
faucet creator creates a new faucet -
komodo-cli -ac_name=PYCC pycli create <fund amount> <faucetget amount> "my arbitrary string"

creator will then externally advertise that they have created a faucet at "my arbitrary string".

A user will then input this string while using the faucet -
komodo-cli -ac_name=PYCC pycli drip "my arbitrary string"

This is simply a proposal. I am open to suggestions otherwise.

@dimxy
Copy link

dimxy commented Aug 6, 2020

The idea is to get a user-defined 'handle' to the cc instance, to retrieve it (instead of using markers to find them all)
To provide uniqueness of it the cc validation code needs to validate there has not been already created an instance with the same string. As the global address is derived from the string using the address index to check the uniqueness should not be a very heavy check (also for retrieving the instance).
The actual planid seems to be the created privkey.
This could be an option.

It looks like the usual txid of the creation tx would provide almost the same result.
If we need a user friendly name we might provide the caller with a pair of the txid and name as the result of creation of cc instance.
Then to have unique global address it is possible to use 1of2 with the creationid as a pubkey.

@Alrighttt
Copy link
Member Author

It looks like the usual txid of the creation tx would provide almost the same result.
This would mean we won't know the private key/address until after the plan/instance is created. Adds an additional transaction if the creation of the plan must know the address.

1of2 with the creationid as a pubkey. 1of2 between which keys?

@dimxy
Copy link

dimxy commented Aug 6, 2020

yes, an additional tx would be needed if we need to send cc value to the global 1of2 address, if it consists of the creationid pk and globalpk.
(Usually the creation tx initially sends all the created amount to the creator pk)

@Alrighttt
Copy link
Member Author

I don't understand the benefit of using creation txid. It just seems like a different way of accomplishing the same mechanism but with additional steps.

@dimxy
Copy link

dimxy commented Aug 6, 2020

it is not necessary to use the creationid in 1of2, it might be any other id or txid, this is a specific for each cc
But it is good to have a single unified way to obtain instanceid (planid) for any cc (to make common things for all ccs).
If to do this based on a string it could be unnecessary step to generate an unique string for those ccs that don't need this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants