(neo3) Alternatives to improve Sender/Cosigners

[igormcoelho]

Scoped Witnesses have been merged (https://github.com/neo-project/neo/pull/968#discussion_r316134580) and after that @morgandream gave good ideas to try to improve the design.

One idea is to remove Sender and put bool flag isSender to inform who will be the sender (a single one).

I would like to further extend this idea and rename Cosigners field to Senders, which is much simpler to understand in my opinion, since not all witnesses are in fact Signatures (they can be verification trigger contracts, or passwork locks, etc).

Each Sender would have same things as cosigners now (a WitnessScope, a referring Account, etc) and also a NetworkFee field, indicating how much of fee each Sender is paying (possibly zero). This is very good, since easily allow people to split fees, specially on a multisig scenario. We would remove the tx root field NetworkFee,that may become just a "pointer" to the sum of all individual fees.

What do you think @MorganDream ,@shargon ,@erikzhang, @vncoelho and others

[shargon]

Invokers sounds better to me :)... and only one as IsSender ? sounds good to me, we can remove one field, but if we have more than 20 cosigners, this flags will cost more... maybe is better if the sender is the first one?

[ZhangTao1596]

What is passwork lock?

[MorganDream]

Hey thanks for opening this issue. I like your idea, expect to solve the Sender/Cosigner issue, your design also allow people to split fees, especially on a multisig scenario, as you have said. This is rather brilliant and will make tx more configurable. Except for the name of Sender, as @shargon said, I still prefer Signer, as verification trigger contracts can still be regarded as signature, and I don't know about password lock.

[igormcoelho]

Example: you deploy hello world contract and send assets to it. It has a hardcoded address to allow verification, no signatures involved... if you summon this contract as Sender it would work,without any signature.

@MorganDream @kickseason Password lock is an unsafe, but possible,mechanism to extract assets on verification, if sender invocationscript provides the given password (no signature involved).

I agree with @shargon , Invokers is a better name. Shargon,one biggest advantage is splitting fees on multisig, although if GAS is also on.multisig,its also technically."splitted". By hardcoding first element as Invoker is like a "workaround" to me... it removes a big possibility, simpler to.understand, in my opinion. Lets discuss this.

[igormcoelho]

So, do you think Invokers is good?

[shargon]

Signers or Invokers are good to me, but we need to define the sender, because is used for transfer, for mint tokens, etc, we need a unique sender i think.

[vncoelho]

I think that Invokers is better, or Senders. Perhaps Invokers.

I think that the idea of having the net_fee field is great, for splitting fees among senders easily. However, imagine if we have 50 Invokers sending 1 GAS and the transaction cost is 50 GAS (net_fee + sys_fee).

If the last Invokers does not have balance we also have lost computational effort verifying the balance of the other 49.

In this sense, maybe a single sender is a good solution, but not so powerful as we would like to.

[vncoelho]

Implicitly, if they really want to split the fee they could also all send to a multi-sig and use it together.

[igormcoelho]

because is used for transfer, for mint tokens

ah, you mean, the address to deposit the minted tokens @shargon? you're right, it's interesting to have the concept of Sender (I missed that on Neo 2). Perhaps splitting fees is not worth the efforts.

Yesterday, @belane did a nice comment on easily attaching Native assets... I think Native NEP-5 is good, because it's "almost" the same as any other NEP-5 (besides the native balance control, which is not available for other NEP-5), so we could take advantage of this balance control, and easily attach Neo/Gas on tx header.

Advantages are: 1) much smaller tx size 2) balance control upfront 3) simplicity to determine transaction format (as @belane commented)

Disavantages: 4) extra efforts to validate a transaction (validating every native asset transfer) 5) extra complexity on tx process layer 6) "assimetry" on the process performed by NEP-5 and Native NEP-5

To fix numbers 4 and 6 (losing number 2), I think we could transform these fields into equivalent running scripts (perhaps by System trigger):

PUSH value , PUSH destination , PUSH destination, PUSH "transfer", Neo3APPCALL neo_hash

And execute those "implicitly" on Application trigger, before actually executing the Script. I'm not planning to recover old tx inputs model, but we need to see if spending bytes on word "transfer" on every transaction is actually worth the user simplicity and efforts of not including this implicitly.

Since the "attach Neo" would require something like this on attribute: Cosigner/Sender xx: NEO_HASH AMOUNT DESTINATION_HASH, this would allow us not just to attach native Neo/Gas, but to perform regular transfers too. So, average user would have an empty Script, which is very good for optimizations.