FLOT compensation discussion

[cryptog]

Because I think it is bad practice.
Each individual should ask for a custodial grant and get it pass in the same way as each FLOT member had to pass a motion to become a FLOT member but I think it would be acceptable for the first payment to use FLOT and T4 as pointed out by @masterOfDisaster since T4 does not deal only with liquidity operations.
I will post my NBT address within 10h from now.

[masterOfDisaster]

Can somebody please explain why a motion is considered necessary to execute a payment that is based on a motion that has passed long ago?

Wouldn’t it make more sense to

• remove FLOT members who failed to act according to the terms by motion and
• continue the FLOT memberships like stated in the terms (including payments)?

[Nagalim]

Why is it bad practice? Is there some attack vector I’m not seeing? Is there even a slippery slope argument for this? The amount of compensation is clearly defined.

[dysconnect]

@woodstockmerkle @ttutdxh would you like to post NBT addresses for your fees?

[masterOfDisaster]

I will do so, too - soon.

[cryptog]

Because then FLOT could reward say, NuLagoon: NuLagoon could pass a motion asking FLOT to pay for its monthly compensation instead of passing a custodial grant.
To me the only argument that is in favor of using FLOT for FLOT compensation is because it is very efficient compared to passing 8 separate grants.

My NBT address for receiving the compensation: BTZtxMx6yfbNzL1jdqPFZnJJYtNZzHuFnx

[Nagalim]

Rewarding NuLagoon via FLOT would require NuLagoon to report to FLOT with a monthly compensation report and FLOT to accept it via consensus. Good point though, that is the slippery slope argument; my rebuttal being that a fixed signer compensation is different than a variable amount.

Efficiency is the name of the game. Think about it this way: we don’t want to wear our shareholders out. The lower the number of consensus statements we require the better the quality of those statements will be.

[woodstockmerkle]

Compensation for FLOT - woodstockmerkle #1 (2015-11-19 to 2016-02-17)

Address: BA5xfjKc8hq7zJSJmaGVCLZkvg5dduEgME
Amount: 435 NBT

[jooize]

Submitted payment addresses

✓ cryptog
✓ Dhume
✓ dysconnect
✓ jooize
✓ masterOfDisaster
✓ mhps
✗ @ttutdxh
✓ woodstockmerkle

Links to respective motions.

I’ve seen no feedback to my ideas about prioritised multiple voting feeds*, and I think no particularly strong arguments against FLOT paying FLOT have been made. We are already handling a lot of Nu funds anyway, and shareholders are free to present a motion to discontinue the service of any FLOT member.

* Post #4 and #21.

I like distributed governance but am not a big fan of too much bureaucratic burden at this state. I do prefer to assume FLOT members should be paid every time until shareholders vote otherwise, without even needing a separate custodial grant.

I can agree with this.

Assuming this is OK, should FLOT create one transaction for all of these, or only for the ones overdue or imminent, and wait a while with the rest? Not sure of the time periods, perhaps all are near the end.

[masterOfDisaster]

address: BLakYKdvewDsph5fY79eZXYrt1oc5qEsM4
amount: 435 NBT

[Cybnate]

should FLOT create one transaction for all of these, or only for the ones overdue or imminent, and wait a while with the rest? Not sure of the time periods, perhaps all are near the end.

A lot of mental loops will need to be made to make something out of all those separate proposals. I suggest a motion or proposal from FLOT to align payments and dates including any deviations from the standard availability. That would greatly contribute to transparency imo. We now face a patchwork which is almost impossible to monitor by anyone and therefore we need to basically rely on self governance from FLOT.

[ttutdxh]

My take on this is as follows:
We already put up the motions for our commitments and our compensations, and we received the necesary support. Shareholders voted for that. That included a payment schedule. Now it is just part of that contract for Nu to pay FLOT. This is a payment, not a vote. If any concerns are to be raised against any part of the procedure, motions are there, anytime. Motions mandate payments, FLOT executes payments.

I have seen this happen in the past, and I think that payments approved by motions should not be subject to another vote(grant). In the past we have done it because we did not have FLOT, but now we do. Let’s not convert the solution to a problem into the problem of a solution.

Regarding the payment method: my idea would be to pay directly into each public key used for FLOT signing in NBT(the ones that do not sign NBT should create a public key for NBT that will be used in the future for this payments and be ready for a possible inclusion in the group with that key, just in case, or reuse the one from other group). That way we avoid mistakes, risks and it is much easier to account.

[mhps]

my idea would be to pay directly into each public key used for FLOT signing in NBT

I’d rather sign with a key that never has significant fund in it. Who knows what might happen to the keys that are used for signing often. Speaking from experience.

[ttutdxh]

I am not saying to use it as a day to day address. Only as a “entry” gateway for these payments. You can then send the funds to your other addresses.

[jooize]

Regarding the payment method: my idea would be to pay directly into each public key used for FLOT signing in NBT(the ones that do not sign NBT should create a public key for NBT that will be used in the future for this payments and be ready for a possible inclusion in the group with that key, just in case, or reuse the one from other group). That way we avoid mistakes, risks and it is much easier to account.

It seems neat, but I don’t like it. We handle the private key for that address every time we sign using Cointoolkit for example (one risk being clipboard snooping), which is also currently under your control (and how many of us even check to see the code hasn’t been changed before signing?). I don’t mistrust you, that’s just the situation and everything should be considered. Though, that’s more of a concern for all the multisig funds in case you’d decide to go rogue.

Arguably, that should be OK if the member doesn’t mind the (perhaps considered minor) risk, but if they prefer otherwise I think we should allow them to.

A lot of mental loops will need to be made to make something out of all those separate proposals. I suggest a motion or proposal from FLOT to align payments and dates including any deviations from the standard availability.

Do you mean we should normalise the FLOT contracts into a “one size fits all”? It would be convenient, but I’m not sure I agree. Maybe.

[Cybnate]

Do you mean we should normalise the FLOT contracts into a “one size fits all”? It would be convenient, but I’m not sure I agree. Maybe.

I think we should. Or we shouid appoint a FLOT manager who oversees FLOT performance, which I wouldn’t be keen on, but is an option to explore.

Decentralised governance is already hard, to have 8+ different proposals to govern is for most of us not feasible including myself. If we pay the proposals blindly we could as well just transfer a monthly amount to an address like we do for MLP and have one person overseeing the the eight proposals and all Shareholders overseeing the FLOT performance in general.

[ttutdxh]

I am not talking about using cointoolkit. You can do it from the desktop client, or using you own tools.

I am the first one encouraging people not to trust anyone. Please don’t trust me. That is why cointoolkit is downloadable and can be run offline. Signing offline is the only way to be somewhat secure, so if you don’t, it does not matter if you use the official client or anything else. You are at risk. Always.

I am trying to address your same concerns with paying to the pubkey.
Can you prove you are paying the signer by sending to his signing pubkey? I can.
Instead, can you prove that the posted address is, in fact, the signer payment address? I can’t.
Forum could be compromised and automatically replacing addresses depending on the user viewing the page, among a rainbow of other kind of attacks. You would be surprised how easy that is. Even the hosting company, and its employees are a risk.

As you say I also don’t think people check the code every time before signing, but you can, and you can eliminate that risk going offline.
I don’t think you can do anything about the forum, your desktop client or even your own online computer.

All said, this is slightly paranoid, but real.

[jooize]

Valid points. Still feels bad to use the address we handle the private key of so frequently. Are those concerns unreasonable?

Members could sign the desired payment address with the private key of their multisig single address. Should improve trust. Probably not going to happen, I guess.

Example:

FLOT NBT multisig single address: BAg28y78t2FyQKsWuFoTpHFuXdFjMyGeCs

Signature:

IEkyiGPbO9y+Dfmu/bRgcmzAjHfXhbKeoOyjBpJ89f79vEhBX9TcimV64i1zExx3XEMIe4yCfco9JuoCxnSrIMc=

---

Cointoolkit online is very convenient, and not trusting someone for that would break the smooth workflow we have now where we just link to it. Perhaps hardcode a link in offline use … Hmm. URI scheme links! nu://verify/<rawtransaction> (not really an around the corner feature)

[mhps]

Decentralised governance is already hard, to have 8+ different proposals to govern is for most of us not feasible including myself.

That is the cost of decentralization. It’s like a jury has to have a diverse set of members. Having a manager is centralising.

I am with @dysconnect above. This very discussion of possibly not to pay after asking each FLOT member to jump through the hoop to get approved individually via a motion, and after the FLOT perform their duty for the first period, without any evidence to show any disqualification, leaves a bad taste.

Instead, can you prove that the posted address is, in fact, the signer payment address? I can’t.

At this point it’s not a big issue I think. We read addresses from the forum to send tens of thousand around.

Let’s spend time worrying about the bigger things, like profit model of Nu.

[jooize]

Summary

Compensation for FLOT - cryptog #1 (2015-11-18 to 2016-02-16)

Address: BTZtxMx6yfbNzL1jdqPFZnJJYtNZzHuFnx
Amount: 366 US-NBT
Motion.

Compensation for FLOT - Dhume #1 (2015-11-26 to 2016-02-24)

Address: B9oFTqTqduqKKRcxHndyHzqbV9HRQjZVYu
Amount: 435 US-NBT
Motion.

Compensation for FLOT - dysconnect #1 (2015-11-14 to 2016-02-12)

Address: BTDNMAPojdgJy2coacM4nKKMQ2Ywh6EVy7
Amount: 435 US-NBT
Motion.

@dysconnect: You removed this address (BTHw62hSByoAnYzKQJvdgqcmw6qTJ6dFEy) from the original post, and I see no new one. Which address do you wish to have your payment sent to?

BTDNMAPojdgJy2coacM4nKKMQ2Ywh6EVy7

Compensation for FLOT - jooize #1 (2015-11-18 to 2016-02-16)

Address: B9dQqqjoX81jLBecRwCEYXSYJgQdYXeLfN
Amount: 435 US-NBT
Motion.

Compensation for FLOT - masterOfDisaster #1 (2015-11-22 to 2016-02-20)

Address: BLakYKdvewDsph5fY79eZXYrt1oc5qEsM4
Amount: 435 US-NBT
Motion.

Compensation for FLOT - mhps #1 (2015-11-19 to 2016-02-17)

Address: BBxdEgU93Lb5UNtiWVPRSnDjXhtkcxvnnV
Amount: 435 US-NBT
Motion.

Compensation for FLOT - ttutdxh #1 (2015-11-18 to 2016-02-16)

Address: BCtHqEGDjrc5sZXJogpxdUDhMcokZunXZs @ttutdxh (Do you want to use BCtHqEGDjrc5sZXJogpxdUDhMcokZunXZs?)
Amount: 435 US-NBT
Motion.

BCtHqEGDjrc5sZXJogpxdUDhMcokZunXZs

Compensation for FLOT - woodstockmerkle #1 (2015-11-19 to 2016-02-17)

Address: BA5xfjKc8hq7zJSJmaGVCLZkvg5dduEgME
Amount: 435 US-NBT
Motion.

---

I’m concluding that we want this done, and that FLOT has the right to execute the transactions for payment of the whole FLOT. I have in mind to create a transaction paying all of FLOT in one go, but I’m waiting for an address from @ttutdxh and confirmation from @dysconnect.

I’ve double-checked the addresses I’ve compiled, and I expect you’ll check them when verifying the transaction anyway.

Sound good?