[Passed] Motion to provide seed funding for B&C Exchange - a decentralized exchange built on the Peershares platform

[Nagalim]

Are exchanges going to end up with a bunch of BKS from the fork? All the NSR on exchange will be separatable from the BKS after the fork, right? So exchanges will probably just pocket it.

[Ben]

All the NSR on exchange will be separatable from the BKS after the fork, right?

Yes, this would be a good reason to pull your NSR off an exchange prior to snapshot if the final motion were to pass.

[Nagalim]

So we’re just giving away a bunch of shares of the company to our competitors, the centralized exchanges?

[lg15x]

This is good news. I am interested in B&C decentralized exchange. I will spend sometime to read white paper carefully. And I am preparing to attend the auction to help for funding this project.

[mhps]

All NuShareholders will receive BlockShares in proportion to their NuShare holdings. Bydoing this it is hoped that NuShare holders will have incentive to provide initial funding for B&C Exchangedevelopment via the NuShare auction custodial grant mechanism, due to the expectationthat BlockShares will have value and B&C Exchange will lower the cost of NuBit liquidity operations.Specifically, we will ask that NuShare holders pass a motion to authorize auctioning 100 millionNuShares.

What is NuShare auction custodial grant and its mechanism? that’s a first time for me.

This one?

However OP says that the 100M NSR will not be created but be taken from those to be burned.

[mhps]

And I am preparing to attend the auction to help for funding this project.

You deserve to own Nushares at its IPO price. Your suggestions on selling Nubits at payment processors were prescient and was cited in my post to suggest ways ahead.

[Ben]

So we’re just giving away a bunch of shares of the company to our competitors, the centralized exchanges?

If you can suggest a way to mitigate that concern, I’m sure it would be considered. There’s no way that I can think of to prevent it from happening if people leave their NSR in an exchange’s address before the snapshot. To the protocol an address is an address.

We can look for inspiration in how the BitShares community has handled snapshots of the blockchain in the past with regards to making sure that individuals received their proper asset if they had funds stored on exchanges.

[JordanLee]

• The “Distribution to Bitcoin holders” section is missing any constraint on how long the BTC have to exist on this particular address, so the same BTC can be reused to get more BKS.

Sorry if this point wasn’t included in the design doc (I thought it was). In any case, it has been discussed and finalized in my own mind that the Bitcoin blockchain would be examined as of a certain block height, resolving the concern raised here.

• The signer selection method does not take the signer’s stake into account. This is fine, as long as shareholders are fully aware of that and don’t just pick signers based on reputation. Otherwise we will soon have 8 reputed signers who are the same person. I think the signer’s stake in BKS should always be visible in the client and serve as one of the most important reasons to select a signer or not.

This is addressed here:
https://bitcointalk.org/index.php?topic=1033773.msg11156623#msg11156623

I will add that shareholders will prefer signers that have pledged a security deposit (in Blockshares), which is discussed in the design doc.

• From the design doc:
  >When a reputed signer posts such a message, he is promising to keep the addresses listed in a
  wallet connected to the blockchain client referenced, which can in turn be contacted by his B&C
  Exchange client at all times in the future, except if he transfers the keys to another reputed
  signer as described in the Signer Incentives section."

Question: Why would he? Is there any incentive to transfer the keys to another signer? Is there a method in place which detects offline signers and automatically transfers the addresses to another signer?

It is expected that the security deposit reputed signers put up will not be released until the keys are verified to have been transferred.

• How can new signers gain reputation if only the most reputed signers are selected? It will require the demand to rise above the expected value by the shareholders such that the reputed signers won’t have a free address slot anymore, correct?

The consumption of a signer’s public keys available as components of multisig deposit address does not occur until they are a top rated signer. They become top rated not by signing but rather by making a public appeal for upvoting. They have to make a convincing case that they should be trusted first.

I hope this answers your question but I am not entirely sure I understand it.

• Last but not least: Reputation voting and scoring
  > The
  absolute value of the number beside the share addresses indicate how likely (relatively) each is
  for inclusion in the block

This is very much the frequency based voting also proposed here in Nu. Is it planned to extend the whole voting mechanism (motions/grants) to this frequency based model? Or is there a reason why Nu motions and grants use a much simpler and less effective voting structure?

The difference between voting in Nu for custodial grants and motions and voting for reputation in B&C is that it is presumed Nu shareholders can vote for all the grants and motions they want to support in every block. In contrast, it assumed that B&C shareholders will wish to upvote and downvote more addresses than can be practically referenced in each block. The mechanism for selecting reputation votes for inclusion is designed to use minimal blockchain space while still including the complete set of information over a series of minted blocks.

[creon]

Thanks for answering the questions, this all makes a lot of sense.

It is expected that the security deposit reputed signers put up will not be released until the keys are verified to have been transferred.

But there must be some kind of fallback solution, right? I mean we cannot rule out dramatic circumstances which won’t allow the signer to pass over the key, for instance due to a hardware failure or the complete disappearance of the signer for whatever reason (including jail or even death). So will those accounts never be passed to another signer in those cases?

Regarding the security deposit, I agree that this would be a nice solution. With CHECKLOCKTIMEVERIFY this could even be done in a trustless way. Actually I would probably even be fine with signatures, since it is only about verifying that its most likely not the same person. A deposit however clearly creates an incentive for the signer to be honest which goes beyond the signing reward, so its certainly better.

The signer selection could also be modeled as staking process to completely remove the shareholder interaction but this is probably a bit too experimental.

[JordanLee]

I hope we will get an answer about possible follow-up financing (possible relative thresholds to the initial amount raised) and what will happen if the realization of the project fails. .

Of course there is a chance that funds will be exhausted and the project will not be finished. If that occurs, investors will have to decide whether to provide additional funding or drop the project. I don’t think either of those outcomes are likely, however. My design document is very complete and no one has even raised a concern or flaw in the design (yet) that wasn’t already considered and addressed. Soon someone will, but we will just adapt the design. I understand you would like me to guarantee it will be delivered on time and on budget, but that just isn’t possible. Anyone who makes such a promise for a project of this kind is dishonest.

Developing a reliable decentralized exchange is a groundbreaking technical feat. So there is risk. However, I regard Nu as a comparable groundbreaking technical accomplishment which was completed 50% under budget in USD terms and delivered in a reasonable amount of time. I am the ideal architect to deliver this novel solution and the Nu development team is best qualified to implement it given our past accomplishments.

[JordanLee]

Though, we have to take into account that we investors are asked to transfer quite some money to some online pseudonyms in exchange for their promises. I don’t doubt that you are planning to deliver, but control measures will help to minimize incentives that might lead to some problems well known from the field of economics: moral hazard and alike.

We are happy to release figures on what has been spent by department:

1. Core development and marketing
2. NuBot development

We are also happy to regularly report remaining funds (I have already been doing this quite regularly).

I’m sure you can understand that our individual contributors would be uncomfortable with us publicly releasing details about their rates and individual payments, as is the case with any organization.

[MaVo]

Thanks for your answers. Keep in mind that transparent financial reporting with regards to the management’s compensation is very often a core element of decent corporate governance and that counts for managers who are not anonymous. I doubt it’s the opposite for anonymous managers
I am as much for transparency as possible. The reason for that is that we as the NU network could build a community that is willing to fund project over project more than any other crypto community out there in the future and add significant value to it. The problem is not a follow-up financing for the decentralized exchange, it is rather the feeling whether such a request is justified or not. At least that counts for me. If we are stuck with development at some point and there is also a lack of transparency, such a situation can snowball really hard and hit the whole NU community in an irreversible bad manner.
Last but not least I have to say that although you are anonymous, I am aware of the fact that the pseudonym Jordan Lee is worth something in the crypto environment and that you have quite some incentive to give your name another boost. I am happy to help with that by providing some money as long as you keep us posted in a reasonable manner.

[Sentinelrv]

I still need to find the time to read all of this, but I have a couple more questions.

1. Since B&C will be using the Peershares platform, will Peershares need to be updated first to include features from Nu like motion voting, data feeds and share creation and burning, or is this not necessary? Previously Teehe was going to do this for us, but it was never fully funded, so it never happened.

2. Since the blockshares will go to everyone who owns NuShares, the Nu shareholders will basically own B&C and decide its future. Since B&C will introduce profit into our network, do you believe that profit would be enough to sustain Nu’s contractors permanently? I’m imagining Nu/B&C shareholders passing a motion where a certain percentage of the profit is distributed to shareholders, but the majority of profit is saved and reinvested in B&C and Nu. If the profit was great enough, it could possibly cover the monthly fees of our contractors without us needing to sell more NuShares in order to afford their services. What are your thoughts on this?

[Ben]

Since B&C will be using the Peershares platform, will Peershares need to be updated first to include features from Nu like motion voting, data feeds and share creation and burning, or is this not necessary? Previously Teehe was going to do this for us, but it was never fully funded, so it never happened.

B&C will use a fork of the Nu repository, not the Peershares repository. That way all of the voting mechanics and two token functionality is already in place. It will still need extensive customization but it’s a better starting point than from scratch.

Edit: Here’s the comment from the white paper:

In addition to the B&C Exchange solution being a fork of the NuBit code repository, the Nu
production blockchain will also be forked.

[creon]

I’m a little confused why the decentralized exchange can’t be added on top of the NuShares blockchain.

I am actually not really convinced by @JordanLee’s answer in the bitcointalk thread:

Theoretically it could be. However, exchange and stable currency are two completely different business models. It would complicate the protocol a great deal to accommodate both business models and increase the risk of an unexpected malfunction in the protocol.

Probably the best reason to separate them has to do with scalability. Creating two blockchains and two networks reduces blockchain size considerably and reduces the number of transactions and messages that need to be processed in each one.

There can be two separate blockchains, one BKC and one NBT, which are both secured using different staking processes but using the same NSR. Of course each NSR is eligible to stake on both chains at the same time, since they are different blockchains - NaS is our friend here.

Any NSR holder can always decide if one or both blockchains get synchronized and if staking is performed on none, one, or both chains. There is no scalability issue for pure NBT users or BKC users.

Both blockchains are different protocols, its only the same proof of stake that can be used on both chains. So any malfunction in one protocol won’t affect the other.

Where do I think wrong?

EDIT: Well not sure how to send NSR in above scenario, so its probably not working like this. I also assume that you spend a lot of thoughts on that, and probably would have preferred a single share solution if it wouldn’t suffer from those drawbacks.

[Ben]

I don’t think you’re wrong, @creon, that is one way to do it. I’ve never looked into multi-blockchain clients, however, so the level of complexity to adjust the existing Nu code to support both sets of protocols at the same time in the same client (or through RPC) doesn’t sound like a simple task.

[creon]

Well i am still thinking about it and was about to delete my post, because the stake of the NSR blockchain can be in conflict when sending NSR, so I think what I proposed is not doable in this form. I let the post there since you answered.

But assuming this inconsistency can be solved, it is not harder than writing BKS. Its really just that you are not using BKS to sign your blocks but NSR, everything else would be the same.

[Joe]

An exchange requires concensus and i don’t see why the nushares blockchain can’t provides that consensus regardless of extra difficulty in implementation. In addition, blockchain bloat is seen as an issue but i also think having an exchange tied directly to nsr allows for far more features than two seperate blockchains. (trustless distribution of dividends for example)

[Ben]

trustless distribution of dividends for example

You don’t need to tie the B&C blockchain to the Nu blockchain to do this. There’s nothing inherently different about the way that B&C would process dividends from how Nu does it that would make trusting the distributor required. They just enter the dividend distribution cutoff time, generate the list of shareholders’ addresses and balances, and then enter the value of the dividend to be sent out – just like Nu.

[creon]

In addition, blockchain bloat is seen as an issue

I still have to check with @sigmike because I am too lazy to read into the code, BUT actually I would say that if you are an NSR user right now, who doesn’t stake, then you can simply throw away the NBT part of the merkle tree, so there is no bloat.

Likewise, and if this is true, then you could run BKC and NBT on the same blockchain and would only require staking clients to sync the full merkle tree, while all other’s could only store and verify the part relevant for the coin they are using (+ NSR).