That I can only decide if B & C works and is ready.
The devil is in the details.
With all the money you could also buy bter.com (pay their debts) and immediately earn money.
Why not buy a company that already makes profits now?
We could also make something like the Altcoin Gemz http://getgems.org/. (Money through advertising) Maybe they want to work with nubits. We could swap the Gemz by Nubits.
If B & C exists, we should buy it. But not before.
That I can only decide if B & C works and is ready.
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.
Yes, this would be a good reason to pull your NSR off an exchange prior to snapshot if the final motion were to pass.
So we’re just giving away a bunch of shares of the company to our competitors, the centralized exchanges?
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.
However OP says that the 100M NSR will not be created but be taken from those to be burned.
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.
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.
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.
This is addressed here:
I will add that shareholders will prefer signers that have pledged a security deposit (in Blockshares), which is discussed in the design doc.
It is expected that the security deposit reputed signers put up will not be released until the keys are verified to have been transferred.
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.
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.
Thanks for answering the questions, this all makes a lot of sense.
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.
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.
We are happy to release figures on what has been spent by department:
- Core development and marketing
- 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.
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.
I still need to find the time to read all of this, but I have a couple more questions.
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.
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?
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.
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.
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.
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.
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)
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.