**MANDATORY UPGRADE REQUIRED** [ANN] B&C Exchange - All users must upgrade

[mhps]

When the system first launches there will be no signers with a reputation and all initial users would be gambling - i.e. the trust model would effectively be no better than a centralized exchange.

B&C not only plans to get seed funding from Nushares it's also going to get something money can hardly buy -- the Nushare holders that is familiar with the voting process (been going on for a half years and ~30 motions voted), and has some psudoanonymous members whose reputation is reasonablly established in the community. The community has some members from the Peercoin community, one of the oldest active cryptocoin communities. I think B&C is banking on old familiar members being at least the initial signers. (How they get $20k deposit is another matter).

if enough signers go offline then the money can't be moved.

Since the signers don't actually sign in person, they just set up some robot servers to do it. I suppose it is not difficult to setup multiple instances of signing "robot" to increase availability.

btw I imagine this could even be used to randomly deploy / destroy signing bots so that the set up is also resistant to tracers/attackers.

edit to add: peerbox -- pre-made secure operating system for minting Peercoin on a RaspberryPi (or a virtual machine instance) might be a good fit for making signing bots.

[1713461469]

1713461469

[1713461469]

1713461469

[1713461469]

1713461469

[1713461469]

1713461469

[1713461469]

1713461469

[1713461469]

1713461469

[masterOfDisaster]

In reading your white paper I think your order book is very well thought out and that it will work well in practice, however I have some serious concerns regarding your proposed exchange mechanism for moving the coins.[...] The biggest problem with this design is it doesn't actually solve the trust problem. Yes, you now have considerably more points that can fail and in theory it should be harder to do so, but all you're basically doing is moving the problem around instead of actually solving it. For example: how are the signers selected? If the signers are randomly chosen then this is really no different to entrusting your money to a stranger. I mean if anyone can participate and if the system were anonymous or pseudo-anonymous then you don't know how many signers are controlled by one party.[...]

I agree that using reputed signers is not ideal as they are a part of the design that might fail. Multi-signature allows for almost half of the signers to fail before things get nasty, but still the signers are one of the weaker points.
With regards to the reliability of the signers - that can be taken care of, if you look at the BCE design paper, page 2 "Summary of Architecture", second paragraph:

Reputed signers may place a security deposit of funds held by other reputed signers, typically in BlockShares.

This is causing a feedback between bad behaviour of signers and their property.
You might argue it's still possible that all the different signers could collude to a degree that is sufficient to steal funds and get the security deposit back - unlikely, but possible.
If a multi-signature deposit is considered not secure enough, it could then be considered to have signers burn the security deposit. They would only be able to get it back if they did behave like it's expected from _reputed_ signers
...that could harm the desire to become a signer, though...

Consider Mercury Exchange, for instance. Mercury uses hash-locked smart contracts to solve the trust problem. It's an approach that will be entirely trustless when transaction malleability is phased out and best of all: it won't require a third-party to mediate. But your solution on the other hand relies on the assumption that enough oracles won't be corrupted for the multi-sig to hold which isn't a provable assumption; At least with Mercury you can reason exactly about the outcomes.

As far as I understand it, transaction malleability is not phased out yet and hence that approach doesn't work yet.
The BCE approach can work, albeit with drawbacks.
I don't know whether or not the hash-locked smart contract approach is compatible with the BCE design, but if it is, I can very well think of a motion that replaces the signers with smart contracts.
Signers might trade the loss of income off for the chance to increase the price of their BlockShares before they vote in favour of that motion.
Anyway I could imagine such a motion to pass, because it would harden the business model of BCE and that should have some value for the owners of BCE.

There's also something you said which is quite concerning: if enough signers go offline then the money can't be moved. That's really bad. So now you have a potentially insecure and unreliable financial system which you can't prove is secure or reliable since its based on elements entirely outside your control.

This is not meant to be a solution, but a recommendation: as with centralized exchanges it helps keeping control over the coins, if they are not stored at the exchange. It might look convenient to store them in a considerably safe BCE deposit address, but they might be safer in the owners wallet.
I consider BCE by design more secure than a centralized exchange, but we all know that there's no perfect security in this world.
There have been enough exchange defaults that have taught not to store coins at exchanges.
Plus they are called "exchanges" and note "stores"

Improvements to the process.

I can think of improvements to most of these problems although I still think the overall design is bad even if it could work.

• If the owner were to control enough keys in the multi-signature then even if all the oracles were to be hacked the attacker would lack the leverage to steal coins  (Your current design gives 100% of the power to an unknown party when this is strictly unnecessary.)

[...]
[/list]

If you give the owner enough keys in the multi-signature to be safe even if all oracles were to be hacked - what would the owner stop from withdrawing the funds?

A variation of that idea would help defending against the "enough signers go offline then the money can't be moved" scenario, though.
Say you have a 6-of-15 multi-signature deposit address and 6 keys are in the hands of the owner.
The signers can still do their job and if they are offline, the owner can still access the funds.
But that would be possible for the owner even if all signers are online...

[JordanLee]

As I understand it, you're using a distributed oracle approach for moving the coins. This is the very same approach taken by the now defunct Coinsigner, Metalair, NXT Multigateway, and several other projects who proposed to use multi-signature to move coins.

I'm not familar with Metalair but I do see an organization called MetaLair.org whose business is outside the scope of cryptoasset exchange.

Coinsigner claims to be creating a dispute resolution or escrow service using 2 of 3 multisig where Coinsigner has one of the three keys. I don't see how it has any relevance to an automated cryptoasset exchange like B&C Exchange.

Multigateway appears to essentially be synonymous with SuperNET, which has some similarities to B&C Exchange but also some important differences. They are using three static multisig signers in SuperNET whereas B&C Exchange can dynamically size the number and identity of signers without any centralized control or software updates. Furthermore, SuperNET makes use of proxy assets (such mgwBTC) that introduce some difficulties. If you want to trade Bitcoin for Litecoin, for example, you must deposit Bitcoin which then entitles you to an equivalent quantity of mgwBTC which is traded for mgwLTC which entitle you to receive LTC on deposit. The supply of mgwBTC is fixed, so the number of mgwBTC will not equal the number of BTC on deposit. Excess mgwBTC that does not represent deposited BTC could be sold fraudulently, for instance. B&C Exchange does not use proxy assets and is not exposed to any of the problems and extra complications associated with it.

tl;dr; Coinsigner, MetaLair or NXT Multigateway have modest to zero relevance to B&C Exchange. Nothing that has been done by them indicates there is a problem with the design of B&C Exchange.

The biggest problem with this design is it doesn't actually solve the trust problem. Yes, you now have considerably more points that can fail and in theory it should be harder to do so, but all you're basically doing is moving the problem around instead of actually solving it.

Peer to peer financial solutions establish trust by distributing responsibility among many parties and requiring transparency, consensus and verification of transactions by many parties. B&C Exchange employs these proven approaches to establishing trust.

For example: how are the signers selected? If the signers are randomly chosen then this is really no different to entrusting your money to a stranger. I mean if anyone can participate and if the system were anonymous or pseudo-anonymous then you don't know how many signers are controlled by one party. You say that reputation is the solution but it is not. Silk Road and other anonymous market places also had reputation systems to curve scamming and it was never 100% effective. Why? Because a signer can still gain reputation and use their influence to strike at an opportune time. They might create relationships with other signers and then plan an exit when their services are being used to protect substantial assets or maybe just create hundreds of signers to gain a majority control (actually, isn't this similar to Stellar?) - so this is a hard trust model to defend.

Signers are not chosen randomly. They are chosen by BlockShare holders in a dynamic fashion. Each time a BlockShare holder finds a block, they can upvote or downvote 3 reputed signers. The protocol only selects top reputed signers (those with the most points).

Reputation is a basis for most economic activity so there is no shortage of precedent here. It usually works, but not always. The system is designed to gracefully handle multiple simultaneous failures of reputed signers without loss of funds or disruption of service. In the case of an 8 of 15 multisig deposit address, the network can handle up to 7 rogue or malfunctioning signers without loss of funds. That is a very broad margin of safety for errors and malicious intent.

How do you gain reputation? When the system first launches there will be no signers with a reputation and all initial users would be gambling - i.e. the trust model would effectively be no better than a centralized exchange. You say there are enough signers where collusion and failure aren't a problem but this isn't a mathematically provable property.

Top reputed signers are likely to be established and well known pseudonymous members of the community. This means a single signer is unlikely to gain control of multiple top reputed signer identities.

Consider Mercury Exchange, for instance. Mercury uses hash-locked smart contracts to solve the trust problem. It's an approach that will be entirely trustless when transaction malleability is phased out and best of all: it won't require a third-party to mediate. But your solution on the other hand relies on the assumption that enough oracles won't be corrupted for the multi-sig to hold which isn't a provable assumption; At least with Mercury you can reason exactly about the outcomes.

It has already been pointed out that transaction malleability is a problem for Mercury's approach. It is also important that no one has a financial stake in promoting Mercury and that NuBit shareholders will provide deep liquidity on B&C Exchange but don't have the same incentives to support Mercury. I hope to have time to provide a detailed comparison of Mercury and B&C Exchange. Briefly, Mercury is an important and noble project but it doesn't have the same prospects for widespread adoption and commercial success as B&C Exchange.

There's also something you said which is quite concerning: if enough signers go offline then the money can't be moved. That's really bad. So now you have a potentially insecure and unreliable financial system which you can't prove is secure or reliable since its based on elements entirely outside your control.

Reliability of a reputed signer is perhaps their most important attribute and shareholders will upvote and downvote signers accordingly. Signers who convincingly demonstrate reliability will be upvoted (and receive income) and signers who are less than perfect will be eliminated as top reputed signers quickly. As explained earlier in this post, there is a high degree of fault tolerance (up to 7 of 15 signers can go offline without preventing funds from being unavailable in the case of an 8 of 15 deposit address).


I will address your suggested improvements later.

[JordanLee]

Ben voiced the following concerns about the practicality of shareholders upvoting or downvoting reputed signers here:

https://discuss.nubits.com/t/passed-motion-to-provide-seed-funding-for-b-c-exchange-a-decentralized-exchange-built-on-the-peershares-platform/2001/268

and here:

https://discuss.nubits.com/t/passed-motion-to-provide-seed-funding-for-b-c-exchange-a-decentralized-exchange-built-on-the-peershares-platform/2001/270

I still have a hard time believing that the reputation system will be that easy to manage in practice.

There's a huge amount of overhead required to maintain trusted signers that will fall (rightfully) on the shareholders. A large amount of automation will be required to make it something that is more than just a bunch of "rubber stamp" votes.

This is the part that concerns me, not finding the signers themselves, but providing shareholders with enough information at the right times to make informed decisions about who to upvote/downvote.

Connecting actual performance metrics of signatories to that flow of information is going to be very challenging using the blockchain as a data transport mechanism. That is, at least until third-party data processing services start to arrive.

Exercise: Mentally scale trading traffic up to 10,000/per day and try to imagine ways that your average voting shareholder is going to be able to keep up.

From my design paper (https://nubits.com/sites/default/files/assets/Blocks%20%26%20Chains%20Decentralized%20Exchange.pdf):

The deposit address request will then be broadcast and the deposit address will be displayed in
the local client. Reputed signers who have a key to sign the multisig address will broadcast a
signed acknowledgement to be placed on the blockchain with a fee that they have received the
deposit address request (using their key for the deposit address, not their reputed address).
The number of acknowledgements received will be displayed in the client next to the deposit
address. Deposit address requests should be stored in the appropriate wallet of all reputed
signers using the addmultisigaddress RPC. Once the deposit address request is broadcast and
an acceptable number of acknowledgements have been received, the user can feel comfortable
depositing funds to the multisig address. Discovering which reputed signers failed to
acknowledge should be easy so they can be appropriately downvoted.

This means the blockchain contains all the information needed to determine whether reputed signers have properly performed their job and how quickly. It is quite easy to construct an RPC method returning how many times every signer has failed to sign a deposit address request acknowledgement within the last x number of blocks. I expect this will be displayed in a very readable format in block explorer websites and other sources of network information. The time (in blocks) for acknowledgement will also be available in the blockchain and could be similarly displayed.

Collecting, displaying and understanding summary information about a signer's performance isn't hard at all. It will be as simple as 'signer Bob failed to sign 4 times in the last 30 days and took an average of 0.0547 blocks to sign' displayed in a table in the block explorer website.

[BCExchange]

There are now 6 days left in the auction. If you would like to place a bid on NuShares and BlockShares, please do so as soon as possible. We will not accept bids past the deadline.

[JordanLee]

mhps makes these observations here:

https://discuss.nubits.com/t/passed-motion-to-provide-seed-funding-for-b-c-exchange-a-decentralized-exchange-built-on-the-peershares-platform/2001/271

Compensation for all the deposit for opportunity cost and security insurance (funds always in hot wallets) is not trivial. So I guess the operational cost of B&C is not much smaller than a centralized exchange.

If the deposit is held in BlockShares, the opportunity cost is equal the value of BlockShares that could have been minted, which is about 2% per year. Shareholders can require the deposit to be whatever size makes the most sense in each case, which could be zero. It may be that if a highly trusted person, such as myself, would be accepted as a signer with no deposit.

While funds are held in connected wallets that are not encrypted, they are actually much more safe than is typically the case with cold storage. For instance, BTER and Excoin both had their BTC cold wallets cleaned out recently because they moved the contents to the hot wallet without understanding something was amiss. So it is clear cold wallet funds are vulnerable. However, due to the multisig nature of deposits in B&C Exchange, in the case of an 8 of 15 multisig deposit addresses 8 wallets would have to be simultaneously compromised. Signers are unlikely to have a static IP address like centralized exchanges and they only communicate indirectly through network broadcast, so it is very difficult to find any attack surface even for a single signer.

Therefore, we can expect the cost of operation to be a tiny fraction of the costs incurred by centralized exchanges, with a theft risk that is dramatically lower as well. This cost advantage will translate into shareholder dividends and profits.

[JordanLee]

Improvements to the process.

• You can use time-locked encryption to create a scheme which is 100% reliable even if all the oracles were to simultaneously explode, losing all keys. This would solve the reliability problem.

My paper covers most of these topics so feel free to borrow ideas, I don't mind.  Relevant sections for your design are the Green Address, Contract Output, and Time-locked encryption sections.

I will take a look at the time-locked encryption section of your paper. The idea is likely a feasible way to transfer deposited funds to a user's withdrawal address after a user defined period of time, even in the unlikely case that most reputed signers were unavailable to transfer funds. It is a great idea that would increase the safety of funds on B&C Exchange substantially.

Thank you.

[Sentinelrv]

Maybe you should add the countdown timer to the thread title now, since we're getting down to the final days. It's possible some people know about this thread, but haven't yet had the time to go through it. Seeing the countdown in the title should help create some urgency.

[BCExchange]

Maybe you should add the countdown timer to the tread title now, since we're getting down to the final days. It's possible some people know about this tread, but haven't yet had the time to go through it. Seeing the countdown in the title should help create some urgency.

Good idea! The announcement title has now been updated.

[mhps]

If the deposit is held in BlockShares, the opportunity cost is equal the value of BlockShares that could have been minted, which is about 2% per year.

I think users generally would want the deposit to be in the currency of the pair which the signer candidate is to sign. For example a signer signing NBT/BTC would need BTC deposit, as Blockshare deposit would have varying values in BTC.

With BTC prices fluctuating so much, many people could think there is a 50% or more risk of value if thier BTC is locked up for a year. Just look at the rates Nu LPCs are charging, more than half of which is exchange rate cost. Those who deposit in Nubits or any accepted assets pegged to fiat would have less worry. So the confidence in Nubits might find its way into B&C cost.

[Uptrenda]

...

Agreed. It's probably impossible to make a security model that's perfect but I can't argue that this approach [of having multiple signers] is safer than a single signer (if the signers are established properly in my opinion.)

If you give the owner enough keys in the multi-signature to be safe even if all oracles were to be hacked - what would the owner stop from withdrawing the funds?

I don't know the full details of the B & C design. I was operating under the assumption that the multi-signature was being used by the signers to move cryptocurrencies between users. I am not familiar with Peercoin, Nushares, or half of what's being discussed here so please forgive my ignorance, but assuming this proposal is being used to move cryptocurrencies between users then my idea is basically this:

T of N multi-signature where the owner O has access to less than T keys and the oracles S collectively never have more than T keys between them so that any combination of O + S keys is always required to move coins. Consider this scheme for example: 4 of 6 where the owner has control over 3 of the keys. He now has majority leverage over the multi-signature yet he lacks the leverage to be able to arbitrary move coins and hence he can't double spend the deposit. The advantage to this approach is it can scale to multiple oracles for fault tolerance but the owner doesn't have to rely on the integrity of those oracles because the leverage in the multi-signature ensures it is impossible to move funds without also requiring the owner's leverage (since he controls at least > N - T keys.) Thus, if the oracles are ever hacked it doesn't matter because the owner still has a say in the overall security- a huge advantage.

If you were to apply this to the B & C design (and forgive me if none of this is applicable - I did admit I wasn't an expert on your technology) you could scale up this scheme to something like 12 of 15 where the owner has 5 of those keys and the oracles have 10. This scheme would allow for multiple failures of either the owner or oracles while still requiring both parties to cooperate - and the idea could be further adapted so even more oracles could fail. To add more reliability on top of this system you can use time-locked encryption to have a subset of the oracle keys recoverable at a future date such that the owner can always independently recover the deposit even if all the oracles fail.

Unfortunately, time-locked encryption still requires trusting that the owner of the time-lock set up the lock reliably as I haven't been able to think of a way to have verifiable time-locked encryption since that would probably require revealing the contents anyway. But the software developers could be responsible for doing this and rotating the time-locks which wouldn't be that terrible since running a software's code is kind of a form of trust anyway and plus if the time-locked keys were ever used before the time-lock expired then this would imply that the developer's messed up and saved the key so the time-locked provider is cryptographically accountable for misuse. The only real problem I see with this scheme is the upper limit on p2sh multi-sig although you could get around this with some kind of additive or threshold ECDSA scheme - the main idea here being leverage.

A variation of that idea would help defending against the "enough signers go offline then the money can't be moved" scenario, though.
Say you have a 6-of-15 multi-signature deposit address and 6 keys are in the hands of the owner.
The signers can still do their job and if they are offline, the owner can still access the funds.
But that would be possible for the owner even if all signers are online...

I'm not sure I understand this. If the owner had 6 keys then he can spend the deposit any time he wants. Since I mentioned I wasn't familiar with the B & C design - maybe this is what you want?

Peer to peer financial solutions establish trust by distributing responsibility among many parties and requiring transparency, consensus and verification of transactions by many parties. B&C Exchange employs these proven approaches to establishing trust.

What about Bitcoin?

Signers are not chosen randomly. They are chosen by BlockShare holders in a dynamic fashion. Each time a BlockShare holder finds a block, they can upvote or downvote 3 reputed signers. The protocol only selects top reputed signers (those with the most points).

Do the BlockShare holders do this manually or does the software do this?

Reputation is a basis for most economic activity so there is no shortage of precedent here. It usually works, but not always. The system is designed to gracefully handle multiple simultaneous failures of reputed signers without loss of funds or disruption of service. In the case of an 8 of 15 multisig deposit address, the network can handle up to 7 rogue or malfunctioning signers without loss of funds. That is a very broad margin of safety for errors and malicious intent.

That's true but this isn't really the same thing. In the real world businesses operate with transparency under a legal jurisdiction. They can sue or be sued and trying to maintain a positive reputation is just a result of having these liabilities. What consequences are there for pseudo-anonymous signers if they misbehave? It was mentioned before there was a security deposit for the signers so there is an economic incentive (how large relative to their influence?) to not misbehave but the fact still remains that there are precedents why this approach is ineffective. Silk Road used a similar trust model to the one you're proposing and scammers were still rampant, security deposit or not.

Another major problem I see with the security deposits is a well-funded adversary can just burn a ton of money to gain majority signer control in the beginning which could be financially advantageous if they anticipate a large volume of future trades. This is yet another reason why I think a lack of transparency for the signer's identity is a bad idea.

Top reputed signers are likely to be established and well known pseudonymous members of the community. This means a single signer is unlikely to gain control of multiple top reputed signer identities.

What basis do the BlockShare holders have to judge the integrity of a signer if there's no real world identity or consequences attached to the signer? This also doesn't address how the system is seeded with reputed signers in the beginning when there are no established reputations.

It has already been pointed out that transaction malleability is a problem for Mercury's approach. It is also important that no one has a financial stake in promoting Mercury and that NuBit shareholders will provide deep liquidity on B&C Exchange but don't have the same incentives to support Mercury. I hope to have time to provide a detailed comparison of Mercury and B&C Exchange. Briefly, Mercury is an important and noble project but it doesn't have the same prospects for widespread adoption and commercial success as B&C Exchange.

I know you're confident but being humble is good too. How do you know Mercury doesn't have the same prospects for widespread adoption or commercial success as B & C? They have a simpler exchange algorithm than you do and their software is already functional, plus - they charge zero trade fees. I wouldn't be so quick to dismiss your competition even if you do seem to have a better incentivisation model. (They have also already fixed the TX malleability issue I raised with a temporary multi-signature approach not unlike your own.)

Reliability of a reputed signer is perhaps their most important attribute and shareholders will upvote and downvote signers accordingly. Signers who convincingly demonstrate reliability will be upvoted (and receive income) and signers who are less than perfect will be eliminated as top reputed signers quickly. As explained earlier in this post, there is a high degree of fault tolerance (up to 7 of 15 signers can go offline without preventing funds from being unavailable in the case of an 8 of 15 deposit address).

I agree that it will work but I still maintain that the signers ought to be as transparent as any real world business for their identities (and thus their reputations) to have any weight. And like I mentioned earlier: how is reputation seeded in the beginning when there are no reputations present? You're essentially going to have to use some variation of what I said anyway to seed the trust hierarchies which honestly isn't that bad so long as any relationships are explicitly stated. Other than that, I wish you the best of luck with the rest of this fund raiser and sorry if this came off a bit harshly.

[cryptog1]

Another set of additional questions, if you do not mind:

- What would be the main difference between B&C and a smart contract-based decentralized exchange if ever the latter is possible?
- Can we increase easily the number of signers required and number of signers? Currently designed I understand that it is  8 out of 15. Any particular reason for this pair?
- How could a trusted signer increase the speed of signing a deposit request message if he or she wanted to?

Tks.

[masterOfDisaster]

If you give the owner enough keys in the multi-signature to be safe even if all oracles were to be hacked - what would the owner stop from withdrawing the funds?

I don't know the full details of the B & C design. I was operating under the assumption that the multi-signature was being used by the signers to move cryptocurrencies between users. I am not familiar with Peercoin, Nushares, or half of what's being discussed here so please forgive my ignorance, but assuming this proposal is being used to move cryptocurrencies between users then my idea is basically this:

T of N multi-signature where the owner O has access to less than T keys and the oracles S collectively never have more than T keys between them so that any combination of O + S keys is always required to move coins. Consider this scheme for example: 4 of 6 where the owner has control over 3 of the keys. He now has majority leverage over the multi-signature yet he lacks the leverage to be able to arbitrary move coins and hence he can't double spend the deposit. The advantage to this approach is it can scale to multiple oracles for fault tolerance but the owner doesn't have to rely on the integrity of those oracles because the leverage in the multi-signature ensures it is impossible to move funds without also requiring the owner's leverage (since he controls at least > N - T keys.) Thus, if the oracles are ever hacked it doesn't matter because the owner still has a say in the overall security- a huge advantage.
[...]

I wouldn't dare to say that I have understood the details of the design in full. This is one of the reasons why I appreciate discussing it!

While your proposed solution would give the owner control over the deposits, I see significant drawbacks:

• The owner is turned to a signer who needs to be online to execute orders because the owner's keys are required to move the funds. By current design a customer can go offline after an order has been successfully placed.
  
• A customer needs to take care of the safety of the multi-sig keys (in addition to the safety of the crypto wallets, but in difference the wallets' safety can't be done with a one-time backup, can it?); I can imagine things go pear-shaped on customers side leading to a total loss of the deposits.
  
• The owner only needs to collude with one (or a few) reputed signers to withdraw the deposit instead of transferring it to a business partner who assumed to make an exchange at B&C
  
• It creates an attack scenario in which a "reputed" signer is (successfully!) selling a huge amount of crypto and doesn't transfer them to the buyer's address, instead withdrawing that huge amount after having received the bought crypto.
  If the gain from such an act outweighs the value of the security deposit, it's game theoretical a good deal, albeit horrible for the exchange and its customers.
  

This attack is only possible if order execution, or more precisely, transfer of funds of the exchanging parties are not handled in an atomic fashion. I'm not sure whether I understand the design in that matter properly.
Trying to increase security by raising an owner's control over the own funds creates backlashes which might effectively reduce the security for each owner.

T of N multi-signature where the owner O has access to zero keys and the oracles S collectively all T keys seems to be more secure in terms of collusion and single points of failure.

A variation of that idea would help defending against the "enough signers go offline then the money can't be moved" scenario, though.
Say you have a 6-of-15 multi-signature deposit address and 6 keys are in the hands of the owner.
The signers can still do their job and if they are offline, the owner can still access the funds.
But that would be possible for the owner even if all signers are online...

I'm not sure I understand this. If the owner had 6 keys then he can spend the deposit any time he wants. Since I mentioned I wasn't familiar with the B & C design - maybe this is what you want?

This is the opposite of what anybody doing business should want
I only wanted to carry out why it's hard to improve the security for an owner without creating overall drawbacks.

[Uptrenda]

This has actually been an excellent discussion and I've learned a lot. I kind of want to keep this going now but I feel like I'm hijacking your thread. Do you guys mind if I post some more questions I might have tomorrow?

[Sentinelrv]

This has actually been an excellent discussion and I've learned a lot. I kind of want to keep this going now but I feel like I'm hijacking your thread. Do you guys mind if I post some more questions I might have tomorrow?

Ask anything you want. Discussing potential flaws and how to remedy them can only lead to a better product in the end.

[masterOfDisaster]

This has actually been an excellent discussion and I've learned a lot. I kind of want to keep this going now but I feel like I'm hijacking your thread. Do you guys mind if I post some more questions I might have tomorrow?

I can only speak for myself...
It has been a pleasure so far reading this thread and trying to get behind B&C and decentralized exchanges in general.
I'd be happy to see more questions, answers and discussions going on, for it will help people understand how B&C is designed and what are the challenges for designing a decentralized exchange are.

The amount of views of the Mercury Exchange thread and this very thread express a high demand for decentralized exchanges.
I consider any on-topic discussion useful.

I'm anxious for learning whether the time-locked encryption approach can be incorporated into the B&C design to provide a fail-safe way for getting deposits back in case too many reputed signers disappear!

[BCExchange]

This has actually been an excellent discussion and I've learned a lot. I kind of want to keep this going now but I feel like I'm hijacking your thread. Do you guys mind if I post some more questions I might have tomorrow?

Yes, please do. Our goal is to create the most robust decentralized exchange possible, so all comments and questions are welcomed.

[BCExchange]

There are now 5 days left in the auction. As of the time of this post, NuShares are trading for 0.0028 USD each on the open market. Our reserve price for this auction is 0.0020 USD each.

[JordanLee]

I agree that it will work but I still maintain that the signers ought to be as transparent as any real world business for their identities (and thus their reputations) to have any weight.

There are certainly advantages to that approach. It is something shareholders can debate and decide on a case by case basis. The protocol only requires that reputed signers be identified by a BlockCredit and BlockShare address, so the system is flexible in permitting almost no information or a wealth of information about a reputed signer.

[JordanLee]

If the deposit is held in BlockShares, the opportunity cost is equal the value of BlockShares that could have been minted, which is about 2% per year.

I think users generally would want the deposit to be in the currency of the pair which the signer candidate is to sign. For example a signer signing NBT/BTC would need BTC deposit, as Blockshare deposit would have varying values in BTC.

With BTC prices fluctuating so much, many people could think there is a 50% or more risk of value if thier BTC is locked up for a year. Just look at the rates Nu LPCs are charging, more than half of which is exchange rate cost. Those who deposit in Nubits or any accepted assets pegged to fiat would have less worry. So the confidence in Nubits might find its way into B&C cost.

I'm not sure I understand why shareholders might want the security deposit asset to be the same as the signing asset. It is also likely that most reputed signers will sign for many asset types.

Placing a security deposit in NuBits makes sense from the perspective that it will have a stable value. Which asset is used depends mostly on reputed signer preference, but shareholders may have something to say about it as well. On a technical level, any supported asset type could be used for a security deposit.