Very interesting reply. Thanks for the links.

mav: mav: Spammers can be punished / rate limited so transactions can be free-of-safecoin-cost but not free-of-consequence.

Good point.

So we could consider owner changes free of cost. Even so… I go back to this:

dirvine: dirvine: for other types it is more debatable as the network has to do something, but that will be a debate I think. Personally I feel it is not adding data really so should always be free, but we need to detail it fully.

… and if we look at an owner change as just mutating a field on an MD, then it would be introducing a special case to make it free to update a specific field.

Even though owner field is maybe most often not very large, it is by no means impossible to imagine a case when most of the MD size is actually comprised of the owner field. Some giant crowd ownership stuff.

And then it becomes so much more obvious that changing ownership is just another field mutation - and is it really good to introduce special cases? I think most agree that they should be avoided as far and as much as possible. But maybe there is a good reason for a special case here.

mav: mav: I think (like bitcoin) so long as the transaction is valid when it’s broadcast (ie has some fee included if that is needed to satisfy validity) then it’s up to the users creating the transaction to decide who among them pays the fee.

Yes, so if there is a cost with owner change, and also if we consider any other MD mutation, which will have a cost: If we are using an overlay network of nodes that are supposed to secure a distributed logic execution by group formation rules and consensus etc., then there will be 1 single node in the group that has to carry out the update, and pay the PUT cost to SAFENetwork.

And this is what I was referring to, here:

oetyng: oetyng: A possible design solution for such a network agreed logic group (NALG), would be that only the node finally doing the update with the signatures, will be reaping the reward.

And that would equal to the users creating the transaction, have decided that the rule is that the first to have all signatures, and successfully updates the MD, pays the PUT fee and reaps the reward.

We might be talking about different things here, because I am talking about agents, executing code on behalf of clients, as to enable decentralized applications. So that’s where “reaping rewards” come in. Clients pay agents to execute the code. A smart contract execution is fueled by gas put in.

However, what you say there, I can not readily process it into some concrete example, so I’m actually not sure I know how you are imagining including a fee within SAFENetwork context.

mav: mav: To further generalize, transactions are rejected or accepted as valid on the rule transaction_function(inputs) == true. The most common case is check_signature(signature, pubkey). So for safe network, multisig isn’t (or shouldn’t be) ‘a set of pubkeys with >0.5 valid signatures’. That’s how it’s described in deprecated structured data, but to me this is the wrong way to go.

What I am designing is actually using both of these things. There is code executed, as to validate any state change, and when consensus is reached on the outcome, the state change is carried out (MD update(s) and/or ImD creation(s)). However, the signatures and pubkeys are required for a node to decide whether there is a consensus: it knows its group, and it has to verify the signatures. Additionally, the hints from David above, was that we would pass in valid signatures when doing the SAFENetwork operation, so the node needs to collect them. And so that’s how these things are tied together in what I am working with.

mav: mav: It should be ‘pointer to an immutable data which is evaluated with the supplied inputs’. That immutable data contains a script which is evaluated by the group for validity with the supplied inputs, but importantly the script is outside the md itself so it removes the restriction of size and complexity inherent to any single md.

I agree. The only thing that differs is that we are talking about slightly different technology/implementation. What I do not understand is how you mean that a group evaluates validity, and reaches consensus, without the use of signatures?

I mean, how does the above replace the use of mutlisig?

I feel there are some big blank spots in our common picture where many misinterpretations dwell.

mav: mav: This is a way to release funds when a document is published and signed. Can’t do that with ‘majority of signatures’ multisig

Actually, the way I describe it, it is done too. It’s maybe not the best way, but basically, nodes are either notified of the document by the publisher, and evaluate it, and then release funds when they agree, or they actively keep querying for the document at some expected location, at some interval, and then when found they agree on the validity and release funds.

mav: mav: Let’s say the cost would only be paid by the final updater This assumes the transaction is signed one-by-one. It may be that the transaction must be fully signed before being broadcast or it’s rejected by the network.

That’s what I meant, like in the code example, the wording was not good above I see. So, the signatures are swarmed and with final updater , I meant the one that is finally doing the update, as it has all valid signatures. This is the one that will pay the cost. And I agree it seems reasonable.

The problem arising is that although someone must do the update as to receive the reward, no one wants to pay the put cost. But then again, if they all agree that the one paying the put cost also reaps the reward, then they will rush to be the one doing the update, and paying the PUT cost. I actually think it could be a good rule. The only hesitation I had was if it was somehow gameable, in that every node wants to be the first one to have all necessary signatures. But I do not see a clear way how to actually achieve that by not sending your own signature as soon as you can (we would of course want all nodes to perform tasks immediately, and not stall and wait for beneficial opportunities).

So, to summarize: