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
reduce learning curve by sticking to ABI construction #191
Comments
@colourful-land more consistent with other chains like xDAI and POA |
Now outdated:
|
If we use this to build a smart contract function invocation:
Does it mean that A. too? Or is that not allowed, which introduces an inconsistency. Is it common for TokenScript authors to want to specify an arbitrary |
I think both are allowed. I prefer to think security on a higher level than syntax. That is, instead of this:
security should work on a higher level, like this:
So it's not really in what syntax can you specify a value (for it to be secure), but in what we do we assert trust towards a certain value. This does not rid the necessity of defining --
|
^ This should go into a doc as one of the principles if it isn't already. It looks much better than the one we currently have. What if for invoking functions, we change ie. from:
to:
and keep It'll make it clear whether it's a payment or function invocation. Is using |
I have some design principles in the whole TokenScript thing which I should have properly written down in the Design Paper. Will do that. I tend to think
That's not a problem;) The problem (of using So this
Is actually another way to express:
Except that it can be used with different packaging formats:
Which allows the data to be used as a function call
as well as an Ethereum signed message:
Where the same data (can be assigned to an attribute) is re-used and packaged in a different format, instead of pre-fixing the 4-byte function code, it is prefixed with "Ethereum Signed Message" followed by a byte-count, which is implied by the I had to admit the whole idea is immature. Actually, in 2017 I was envisioning the signed messages (like buy orders or magic links) passed around in an ASN.1 format like DER to conserve the block space, so I didn't think something like There are good arguments that Imagine you have a wallet-contract that has a function which simply sends a transaction as you dictated with to, data, value tuple:
Then you can do this:
Or this:
In either case, |
BTW did you mean for this entire issue to be posted to https://www.tokenscript.org instead, since it's design consideration? |
Consider this:
I'm inclined to do this:
How do you think? Note that I used
contract
instead ofref
as an attribute for<to>
because they meant differently. One is a reference to contract; the other is a reference to an attribute.P.S. This has to be considered together with #163
The text was updated successfully, but these errors were encountered: