-
Notifications
You must be signed in to change notification settings - Fork 1k
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
NetworkFee calculation method #840
Comments
Neo Segwit? eaehauhuehauehauea @erikzhang, I think that I agree. However, for cosigner with different Witnesses we could have a problem and also #835 is an important feature. |
I understand the problem, for me is good because you will pay for the verification execution. Do you want to include this in #791 ? |
Erik, I think it's possible to calculate the network fee, but it will likely create inv script two times. public int Size =>
sizeof(byte) + //Version
sizeof(uint) + //Nonce
Script.GetVarSize() + //Script
Sender.Size + //Sender
sizeof(long) + //Gas
sizeof(long) + //NetworkFee
sizeof(uint) + //ValidUntilBlock
Attributes.GetVarSize() + //Attributes
Witnesses.GetVarSize(); //Witnesses
============= Anyway, I still like your proposal Erik. It makes things much simpler to handle. As long as we can archive witnesses in time (forbidding access to |
You can't estimate the size of |
Agree. |
Ok, if we follow this direction, we need to discuss one thing. Since Witnesses are not supposed to be charged (by space or computation), I strongly suggest we consider a limited computation on Witness computation. |
I have 3 options:
@neo-project/core |
Lets try to put more options Erik... |
@igormcoelho Maybe we can apply this limitation. But it doesn't solve the problem. |
1 is like now on #791, right? |
Yes. |
it is part of a complete solution Erik. Limitation allows size of verification be the a limit to the consumption, since there are no loops. I think we can charge verification on network fee (because it can use hashing and ecc), by a simple opcode parsing. Invocation cannot be charged, but we can disable all interops, so only pushes and basic vm logic there, nearly no costs apply to it. We put a max size on invocarions and verifications, although not charging invocations, tx larger than that can be denied. It think this is a reasonable way to proceed. |
I prefer the option one |
I prefer option one adjusted to what @igormcoelho is defending. |
@erikzhang even if only singlesig and multisig are allowed, will we still be able to invoke deployed contracts on verification? if we do this, we eould need to pay in advance for an arbitrary contract, same issue as before. |
I can |
Let's write about the core ideas of our directions here neo-project/specification#3 and reach an agreement about the re-verification as well...aheuahea I support more in your direction brother, @igormcoelho:
|
@erikzhang You can do that... this is very cheap, up to the maximum size allowed. |
But you don't charge the size, this method is the same as option 2. |
We would charge size Erik, implicitly (or explicitly). I'm proposing to charge only the verification part of witness (not invocation part). |
That's what I said. I can make the invocation part be very long by |
Yes, and this would be controlled by max invocation size only. How much size should be allowed on invocation? I hope not much, there's no use for long invocation scripts on witnesses. |
@vncoelho We are talking about fees, not re-verification. This is another topic. |
Imagine a 99-of-100 multi-signature. |
Just was exactly what I calculated now: 100 multisig is 6400 bytes 😂 This is already quite big, and unnecessary for usual cases. If someone wants bigger than that, it is not usual, it can deploy in this case, and fill in signatures one by one, in several transactions, using timelock. This way, it can have a 100000 multisig. You can allow multisig on verification witness, but lock invocation size. This effectively locks things for "common" uses. After that, deploy can solve anything, no need to do everything on verification. And to be honest, we can do 99-100 multisig, soon enough I hope, with Schnorr signatures. Fixed invocation size (64 bytes). So, if limiting the whole tx to small sizes, all witnesses are naturally locked too, and technology will self-adjust (or move to deploy). |
Let's step by step. First, we follow the option 1. Then we limit the witness scripts to avoid re-verifications. After that, let's see what's the next. |
Agreed. |
@lock9 please create an "easy" task: max witness size. It could be added into Policy jsom and filtered by SimplePolicy. Good for newcomers. The only problem is that we dont have SimplePolicy anymore 😂 (so it may become hard... but its worth trying) |
A medium level complicated task is to parse script and compute its costs (linear costs). Nothing should be processed, just parse and cost. This is another useful task on this issue. An elaboration over this is to benchmark the cost over CheckSig,CheckMultiSig (with many differebt sizes), and script parsing, for big and small scripts too, just a hunch on computational costs of the approach. |
@lock9 I'd also like to continue my PR on jumpless verifications,which was frozen but can be unfrozen now. |
@erikzhang one imporrant thing is missing here |
its already defined that contracts wont access witness data, ok, good for space pruning. Regarding tx witness execution cost, for new pubkey type it could be free in my opinion, and for other witnesses? Otherwise, a valid idea is to charge from Sender, as basic pubkey witness, even if it passes and other witnesses fail. This way we can have loops, secure charging up to max gas funds on verification,and publish BADTX even if other witnesses fail. Limitarion will apply to.script of sender. |
I think we don't need this now. |
@igormcoelho, I need to understand better the current situation:
|
It can be closed? |
I guess all points should be decided already, right? So it's fine to close. |
Currently, our calculation of the
NetworkFee
of the transaction is divided into two parts: the one is based on the size of the transaction, and the other is based on transaction verification.So, to calculate fee for a transaction, we need to get the size first. To get the size, we need to fill the
Witnesses
first. To fill theWitnesses
, we need to sign the transaction first. To sign the transaction, we need to fill theNetworkFee
first. So that is impossible to do.Therefore, I propose that we only charge for the part of the transaction other than
Witnesses
. Because once a transaction is included in a block, theWitnesses
field is useless and can be deleted in the future. Therefore, the space occupied byWitnesses
can be free.@neo-project/core What do you think?
The text was updated successfully, but these errors were encountered: