Tier 4 Fund Management Discussion

[JordanLee]

I would like to see a clause in the motion that the group can excercise discretion, and decision making of the group is visible to the shareholders all the time.

I added the following text to the draft of the motion:

The preceding should be interpreted as guidelines, and FLOT may exercise
discretion. Communications between FLOT members regarding decisions on
how to use funds must be publicly visible.

[Nagalim]

There are 2 reserves. Let’s assume an attacker chooses to evaporate both reserves into each other, what would that look like? If you give me point 2) and we have a 100% reserve, it would look like this:

1. Attacker buys 10% of NBT liquidity (20,000 NBT) breaking the 40% threshold. This causes signers to start dumping NBT. Attacker buys all of it (total: 100,000 NBT). He does this when BTC is high, because he has the opportunity to time it while Nu does not (signers are obligated to push back).
2. T4 now has 160,000 and begins to buyback NSR. This is good, but isn’t super fast. The statement here is that turning NBT into BTC is fast while turning NSR into BTC is slow. This causes a buildup of BTC in tier 4 (which is actually a liability).
3. Attacker sells NBT fast again, tripping signers and selling T4 back down below $80,000.

In that circumstance, the attacker was able to win a gamble with us of a large amount of money. Our saving grace was the use of funds to buyback NSR and the possible repurcussions that could have had. Increasing the spread to 30% dampens the impact of fluctuations. We will always be vulnerable to this kind of attack as long as we peg BTC, but we can raise the liquidity bar required to interact with our signers directly.

[JordanLee]

I just added this content to the draft motion:

In order to form FLOT, at least 3 signers must be selected by motion. Additional signers will be accepted for a period of 14 days after this motion is passed.

[JordanLee]

The attack scenario articulated by Nagalim has a premise that the BTC price can be predicted, which I don’t accept.

He makes some valid points about asymmetries in liquidity between tier 4 sell side and tier 6 (buy side), but I believe that asymmetry is of minimal importance when selecting the threshold at which to intervene in the currency market.

[Nagalim]

Let’s pretend we move the % up to 49%. Now, the signers are basically constantly selling and buying, much like T1-3. Except now the volatility risk is not decentralized, it is essentially taken directly out of Nu’s marketcap. The % gap (‘virtual spread’ as I call it) allows us to dampen the effects of volatility using park rates and decentralized liquidity. A wider spread allows us to sustain a wider volume of volatility before we engage multisig funds directly.

If I want to sell a lot of nbt it would be better for me to put it up as sell side, kick the percentage over the 40% barrier, and force signers to buy from me at the spread premium (or just under so I step in front of the other custodians). The threshold determines how much liquidity I need to activate the signers, in all scenarios.

1. Put up 100,000 buy side. Force signers to sell at $0.99.
2. Take down buys and put up 100,000 sell side. Force signers to buy at $1.01.
3. Profit at Nu’s expense.

If we go from 40% to 30% we make it so the threshold for that kind of manipulation is $40k instead of $20k (Assuming 200k total liquidity). If we factor in T5 and things like fixed cost and ‘shift’ in additional to normal supply and demand rules, doubling the threshold can give us a good bit more of a comfort zone than even that $20k. With a 30% threshold the amount of liquidity required to attack the network in such a way more than doubles over a 40% threshold.

[mhps]

I have asked many times but never get an answer: what does it require to be a multisig signer group member?

Starting from easy questions:
Does the signer need to run an active bitcoin node all the time?
How often online to access the web and ssh is needed?

[Nagalim]

A signer does not need to run a full node, simply sign a Tx that is passed to them. (I think)

A signer must be available for signing consistently, which means reachable by bit message or whatever. @JordanLee made the suggestion 5 days a week and 45 weeks a year. FLOP should coordinate so there’s always signers available.

[dysconnect]

A suitable work flow would look like this:

1. Retrieve unspent outputs for the multisig address. It better not involve scanning the blockchain oneself, but I don’t know anything about the API of the blockexplorer. If we can’t properly automate fetching this data from the blockexplorer we can create a small database to keep track of the outputs, and put it on a server or github. I prefer github either way in case blockexplorer is unavailable.

2. A first signer “proposing” a transaction would choose suitable outputs and sign a transaction. Without nud you’ll need to keep the private key and do some scripting.

3. The signed transaction is broadcasted (e.g. on the forum, via github). The next signer picks it up, signs it, and broadcast via the same medium, so on so forth.

4. When there are enough signatures somebody would use sendrawtransaction to put it through the network.

(5. Somebody with access to the blockchain or blockexplorer would update the unspent outputs)

I prefer not to use Bitmessage in any part of the main workflow as it’s not suitable for mobile networks.

[JordanLee]

I have asked many times but never get an answer: what does it require to be a multisig signer group member?

Starting from easy questions:
Does the signer need to run an active bitcoin node all the time?
How often online to access the web and ssh is needed?

It isn’t clear whether full Bitcoin nodes will be needed, because it depends on which multisig client signers decide to use. Armory is popular and requires a full Bitcoin node. There are web wallets as well as local thin clients that also support multisig transactions. Which software is best for Bitcoin multisig transactions needs to be researched and resolved. For NBT and NSR, signers will need to manage funds using a Nu client via RPC, or command line. The process of creating an NSR or NBT multisig address and spending from it is described in detail here. The process isn’t exactly user friendly but it doesn’t require programming skills or anything like that.

As Nagalim mentioned, availability will need to be coordinated so that enough signers are always available to form a transaction at any time. It isn’t clear how formalised this will need to be, but with multiple backup signers, scheduling time you will be unavailable probably doesn’t need to be done meticulously.

Signers need to watch liquidity figures on a daily basis and be available for contact by other signers. It would be ideal if they are regular forum readers.

When it is time to transfer funds, in the case of an NSR or NBT address, one signer will start by creating and signing a raw transaction, then send the raw transaction to the second signer, who signs it and passes to the next signer until it has enough signatures, at which point it will be published to the Nu network. The process with Bitcoin is likely to be even easier.

While I can’t predict how often action will need to be taken, it is likely to be between once a week and once a month. After doing it a couple times, I think signers will find the process easy and comfortable.

Does anyone have any additional questions about what it means to be a signer?

[mhps]

one signer will start by creating and signing a raw transaction, then send the raw transaction to the second signer, who signs it and passes to the next signer

Does the order to sign matter? What if the second signer is out of touch and holds up signing by the third?

Is using bitmessage to communicate a requirement?

Is delegating allowed?

Can a signer mess up and cause loss of fund?

[Nagalim]

Does the order to sign matter? What if the second signer is out of touch and holds up signing by the third?

no, but people need to be signing the same Txn that is passed around. Signing separate transactions at the same time using different signers is a fork of the FLOT.

Is using bitmessage to communicate a requirement?

no

Is delegating allowed?

no, these are private keys

Can a signer mess up and cause loss of fund?

not unless there is consensus about the mistake. So please make sure you can verify the Txns you sign.

Disclaimer: I don’t really know anything, so…

[mhps]

Does the order to sign matter? What if the second signer is out of touch and holds up signing by the third?

no, but people need to be signing the same Txn that is passed around.

So it’s not passing around, it’s more like the first signer signs and broadcasts to everyone else to sign and broadcast like @dysconnect said above. Sounds chaotic if there are 7 signers.

Is delegating allowed?

no, these are private keys

That doesn’t answer the question, which is a matter of policy. A sends passphrases to B and says 'Hey sign it for me while I am on holiday please".

[Nagalim]

the first signer signs and broadcasts to everyone else

No, the first signer signs, then the next signer signs, but it doesn’t matter who the next signer is (any other member of FLOT). Then that signer passes it on. If a signer signs a different chain of signatures they are forking the transaction.

[mhps]

No, the first signer signs, then the next signer signs, but it doesn’t matter who the next signer is (any other member of FLOT). Then that signer passes it on

So every signer except the last one has to make sure the next one signs, if not, one and only one alternative has to be chosen.

[Nagalim]

Someone, anyone, even someone not on FLOT, forms a raw Txn and broadcasts to the FLOT. A member verifies the Txn, signs it with a private key, and rebroadcasts. Another signer verifies, signs, and rebroadcasts. And so on. Once the threshold is reached, anyone, even someone not on FLOT, can broadcast the signed Txn to the network via a node.

[mhps]

signs it with a private key, and rebroadcasts

What’s the difference from what I said above?

[Nagalim]

You don’t need to make sure the next one signs, broadcasting it should be enough. Once a Txn accumulates enough signers and is broadcast to Nu it will consume the outputs and render any signing forks useless.

[mhps]

You don’t need to make sure the next one signs, broadcasting it should be enough.

In my post I did first ask if broadcasting is to be used and you said no. See the link above.

I want to understand clearly close attention needed.

[Nagalim]

oh, sorry, you’re right. Why is that chaotic? Just have a forum post where the person who forms the raw txn makes the post, then each signer in turn replys with their hash.

[dysconnect]

Ideally one would sign a transaction and pass it to another person, and the transaction is passed down until it gets enough signatures. The next person might not be available or reliable for signing, so by chance you’ll need to try somebody else.

So you may as well just broadcast the signed transaction e.g. on the forum and just let the first FLOT member who sees it do the job. After this next person signs the transaction, he will need to broadcast the transaction again, and the signer that goes after him will need to sign this newly signed transaction.

Two people might try to sign the same transaction at the same time, producing a fork. Practically there’s only one valid fork but it means one of the two people would need to sign again, this time the transaction signed by the other one of the two people. There are coordination issues but it isn’t serious, we just need a protocol that has locks and timeouts on top of the broadcasting.

By the way, once the group is formed we’d be creating a first multisig to receive the current balance of Tier 4 and that likely requires coordination within a forum post. We’ll see how smoothly that goes.