Quote from: fav on June 15, 2015, 09:00:46 pm

Without BM & team BitShares is probably dead, and we can't blame them if they want to get paid for their work.

Yes.  It was always the case that if BM and team announced "we are done with Bitshares, goodbye", then the project would be pretty much done for.  Bitshares is not at bitcoin levels of adoption where many others could arise and carry on.

...

 

Let me try to clear a few of these up:

...

 

In case you don't watch the show, it's a good thing.

Hah, . Let's just hope the non-dev investors in Cryptonomex aren't able to use their voting power as shareholders in Cryptonomex to oust people we trust (like bytemaster) from important decision making roles.
Spoiler (apparently SMF doesn't have a spoiler tag): [spoiler] _{Then again Richard makes a pretty incompetent CEO and probably should just stick to the tech.} [/spoiler]

I trust bytemaster's interests to be aligned with BitShares. I just hope the other mysterious investors' interests are/remain aligned with BitShares as well. Well, at least long enough for BitShares to grow big enough that we are no longer dependent on Cryptonomex anyway. At that point the BitShares community would be capable of funding devs, potentially poaching Cryptonomex devs (you guys aren't signing a non-compete clause that would prevent you from working on similar technology after leaving the company, right?), to fork off the most recent free software licensed version of Graphene and continue development of features with a new implementation that is also free software licensed and that Cryptonomex has no claim to.

This thread should probably be moved to Random Discussion.

But anyway, I'm glad you brought up the show. I did enjoy the episode and remain hopeful (but somewhat skeptical) that it turns out to be a good show, however I found the parts where they are talking about eradicating debt for the good of the regular people so incredibly frustrating and naive (as well as how the anti-corporatist slant of the show often seemed to instead devolve into anti-capitalism).

First, these are contracts entered into by consenting informed adults, so how is it morally justified to say they shouldn't have to pay anymore simply because it has become more of a struggle than they anticipated.

Second, having the option to go into debt is a fantastic thing. What would a world look like where people were too afraid to enter into such financial contracts (say because they were too afraid of the risk that hackers would be capable of completely erasing all credible information that the parties had entered into such a contract in the first place)? You might no longer be able to live in a house until decades later when you could actually afford to purchase it in full, but hey at least you would be able to die with a larger net worth because of all the interest you avoided paying  . But with loans, you can live in that house earlier when it matters more (like when you can enjoy it more, or the bigger size is important to provide room for the children) at the cost of dying with a smaller net worth. Parent/grandparents giving their inheritance to their kids/grandkids can help smooth this out without debt, but people shouldn't have to be so dependent on that generosity (or just the financial ability of their parents/grandparents) to be able to have a good life. It is even more problematic when you look at high cost of certain goods/services that are an investment into ones' future income earning potential, such as a college education or a even just a car to drive to work. Those that cannot get loans to get an education or a vehicle will be more likely to be trapped in a low-wage job from a limited selection pool (since their ability to reach other potentially more profitable job opportunities would be limited by lack of adequate transportation or lack of qualification). And this isn't even mentioning how businesses would be negatively affected without the ability to go into debt to get funding to grow their business.

Third, there is another human being on the other side of that contract even if there are a lot of intermediaries in the form of the big bad corporation in between. So what about the regular households that will for example lose their retirement funds if all the other households could just stop paying their mortgage and college loans?

Fourth, I find it funny that their plan is to try to destroy financial records to put people on a more equal playing field. Putting aside the practical difficulty of the task (especially destroying offline backups), I just find the whole thing to be a bit ironic. Although I don't think Bitcoin was mentioned in the pilot episode, the lead character seems like the kind of person that would support Bitcoin and blockchain technology. But blockchain technology is exactly what would significantly reduce the risk of losing these important financial records from hacks or cyber attacks. The immutable nature of the blockchain and the fact that it is distributed to many different computers that are part of a decentralized network means that their grand plan would be considerably more difficult than it already is if they lived in a world where all financial instruments (such as loans) were recorded on a global decentralized blockchain.


But again, with that all said, it still looks like it can be an entertaining show. Also, I like how the hacking on the show is far more believable than most other Hollywood movies and shows .

Bytemaster, please don't make stealth transfers require only a single key permission to spend the blinded output balances. That would mean there would be no way to have multisig protection of balances received through stealth transfers starting from the moment they are received. The user could of course quickly move the balances to another account (obviously not their main account since that would just compromise the privacy of the stealth transfer unless it was funneled through a CoinJoin-like process first [1]) with appropriate permissions set up shortly after receiving it, but this would be an annoying (and costlier) inconvenience. And if the funds were sent unsolicited, there can be an arbitrarily long period of time during which the funds can be stolen by an attacker who knows the account's active private key and is scanning the blockchain with it looking for opportunities to make money.

Of course stealth transfer recipient's having many different permission structures harms privacy. If only one account has an M-of-N multisig set up for a particular value of M and N, then sending a stealth transfer to that account while respecting their multisig permissions would create an output balance with a M-of-N multisig spending permission, which would clearly associate the supposedly stealth balance output to the named account.

For maximum privacy while still balancing usability, I think all stealth transfer output balances on the blockchain should follow the same spending permission system that I will describe next. Each account that specifies that it can receive stealth transfers should also specify three public keys: a hot key, a cold key, and a third-party key. Each of these keys will be converted into an obscured version for use in the output balance using child key derivation. The obscured hot key will be derived from the hot key using a child index of sha256(sha256(V)), where V is the shared secret. The obscured cold key will be derived from the hot key using a child index of sha256(sha256(sha256(V))). And, the obscured third-party key will be derived from the third-party key using a child index of sha256(sha256(sha256(sha256(V)))). The different hashes are used so that if any of the three keys are the same, that equality relationship will not also be visible with the obscured keys. Furthermore, the index for deriving the obscured third-party key from the third-party key (for use in possibly signing a spending transaction) can be shared with the third-party without exposing the decryption key for the memo or the blinding factor for the blinded balances to the third-party. To spend the balance the network would require a signature from either the obscured cold key OR signatures from both the obscured hot key and the obscured third-party key. The idea is to allow the cold storage private key alone to be able to spend/recover the funds [2], or alternatively to spend/recover the funds using the hot private key and cooperation with the owner of the private key corresponding to the third-party key assigned to the account (this allows two-factor authentication even for spending output balances of stealth transfers). Now if the user is not interested in relying on a third-party, the third-party key in the account can be also set to the hot key, thus allowing either the cold storage private key or the hot active private key to spend the balance. Regardless of the setup, the public always sees output balances with three unique keys in the spending permissions, so they cannot determine whether it is a multisig setup or not.

I also think it is important to add EdDSA cryptography to Graphene so that users have a computationally and user friendly way of computing threshold signatures. The new multisig permission system in Graphene is very powerful but it has two characteristics that can be perceived as flaws in some cases. First, the number of signatures needed (and thus transaction fees) scales with the number of parties that need to sign, whereas threshold signatures are indistinguishable from a single normal signature. Second, the permissions structure is public (some entities, such as companies and organizations, may wish to hide such information with the opaque threshold signatures even though it comes at the cost of having to manually update public keys any time a single key in the permission hierarchy needs to change and also needing to coordinate the signature generation process off-chain). Furthermore, threshold signatures become very useful in stealth transfers because any of those three keys can have their independent opaque threshold scheme (I think... do hierarchical deterministic wallets using EdDSA still allow threshold signature generation?). So you can imagine that the third-party key added to an account would actually be a result of some threshold scheme set up by the two-factor security company.


[1] By the way, I think it is so important to make sure the blockchain has all the support it needs to make CoinJoin-like processes easy and efficient to do, and then also have some standard code built into the wallet frontend and backend that implements that process. It would be great if the following was possible. The user's wallets could submit to the wallet host a pseudo-transaction with blinded input operations that each pay a small unblinded fixed fee, blinded (with random blinding factors) output operations that each pay a small unblinded fixed fee, and the blinding factor difference to make the balance proof possible. Then the host waits to collect these pseudo-transactions (for the same asset type) from many different users and aggregates them together in random order into a single transaction (the wallet host will have to balance inputs and outputs by adding to the transaction a commitment to 0 value with a blinding factor equal to the sum of the collected blinding factor differences, and also sign that commitment with the blinding factor to prove it is committed to a 0 value). Then the wallet host sends the completed unsigned transaction to all those users so they can verify, sign, and send the signatures to the wallet host who would then finally broadcast the final signed CoinJoin transaction. The wallet host knows the metadata of which inputs map to which outputs (but not the amounts which are blinded), but the public doesn't know either the amounts or the mapping.

[2] I believe it is also necessary for the hot active private key to always be set up such that it can be derived from the cold storage private key since the hot active private key is needed to derive the one-time private key for the output balances of the transaction which is in turn needed to calculate the shared secret V. In fact, going from the one-time private key to V also requires knowing the recipients public key, which means the recipient of the transaction must be known. Since there is so much free space available thanks to the blinding proofs, it shouldn't be any problem to use some of that space to store important information to help recovery. For example a decryption key derived from the one-time private key could be used to decrypt a fixed-size first segment of the encrypted memo that stores information meant for the senders eyes only. This information would store a small checksum and the account ID of the recipient (and perhaps even the recipient public key as well to speed the process up if space isn't a problem) which would provide enough information to then derive V. The encrypted memo may even have a fixed-size second segment which can be decrypted by an observer (assuming the recipient account assigned an observer account for stealth transfers) and would have a checksum to let the observer know that this transaction output was meant for them and the account ID of the recipient so that the observer would know who to inform of the transaction. Then the rest of the encrypted memo would be the third segment which would be the original encrypted memo that uses V as the encryption/decryption key. The observer could scan the blockchain with just a single key to quickly determine whether the transaction outputs of a stealth transfer concerned them or not, and if it did, with a little more work could determine the recipient account that (if the account was a customer of the observer) would need to somehow be informed of the existence of this transaction since it would very likely be a stealth transfer of some asset to the recipient. That way senders don't need to rely on off-chain methods of communicating the existence of a balance output to the recipient, and also it is in theory possible for the user to recover all stealth balances without needing full access to the blockchain by delegating the scanning task to the user's observer (perhaps after compensating the observer with some fee) and without needing to reveal any information to the observer that could allow it to steal (or even view the balance of) the funds.
Edit: Actually, after thinking about the cryptography more, I believe what I missed was that the "free" space in the signature used in the memos could only be useful for those who are supposed to be able to see the unblinded values. If I understand it correctly, the random nature (to those without a decryption key) of the encrypted memo means that outsiders cannot tell which version of the commitment in the ring for each blinded bit is the "corrected" one, but those with the decryption key would easily be able to deduce that information and thus figure out what the underlying value actually is. So, again assuming I understood correctly, it is only possible to design the cryptography to share the "free" memo space between the sender and receiver (both of which must be able to get access to the plain-text amount), but not an observer who is not supposed to know the plain-text amount (the observer would just need a separate small fixed-size memo field outside of the signature if we would want it to be able to do its job).

Confidential addresses couldn't vote because no one knows the balance. 

Yeah, which means people protecting their BTS balances will be in opposition to network security.

What if it was possible to count some of the blinded BTS votes if the owner elected to share the blinding factor with some trusted third party (thus exposing their balance amount to that third party)? You could have some subset of balances that all voted for witness 8, and the trusted third party could provide proof that the summation of the blinded values of all the accounts in this subset is a BTS amount X (they can sum all the blinded factors they collect and use that to sign the proof). Then the network could recognize that and add X votes to witness 8's approval rating.

Light wallets need out of band notification.   

But what happens if you lose your local data (but not your private key). You in theory have enough information to recover access to your funds if you had a full client with access to the blockchain. But at 100,000 tx/s it is not feasible. And you don't want to give your private key away to someone to do it for you because they could steal your funds. Observer keys could allow you to expose your financial history to a trusted third party (but not access) for the sake of recovering your account from a single brain key imported into a lightweight wallet.

In this post https://bitcointalk.org/index.php?topic=1084460.msg11570492#msg11570492

Stan suggest it is possible NXT (and/or other interested coin) and BTS2.0 to co-exist on a single blockchain.

Assuming NXT or other coin is interested, how is this gonna work?  what are the next steps, conditions etc. Is such blockchain gonna have 2 tokens, or just one NXTBTS2.0 ?

Here is my (completely unsubstantiated) guess as to how it could possibly happen: https://github.com/cryptonomex/graphene/wiki/blacklizard-app-finarch

Basically imagine NXT (or some other coin that may be more open to the idea) becoming a UIA on the BitShares blockchain, but where holders of this special NXT UIA get to elect their own delegates to operate their own independent DPOS-based chain which is still able to (via a majority of the elected delegates agreeing) interact with the assets on the main BitShares chain. They get to use the BitShares BitAssets, charge fees (e.g. in BitUSD) for the transactions that occur as part of their app or DAC, and they can even distribute some of these collected fees (after paying operational expenses) to the NXT holders as a dividend.

Market Orders can charge just $0.01 to place and then charge $0.20 when they get matched and be free to cancel. 

I hope that $0.20 charge can be for all partially matched amounts originating from the single placed order collectively, and not $0.20 each time there is a partial match (the number of which could be unbounded and out of the control of the user that placed the original order and pays the fees). That fact is also the reason why I think cancels should be free, since a single short order can be split to an unbounded number of short positions. Better yet would be to just get rid of the $0.20 fee, keep the $0.01 fee to place the order and also add a percentage fee like 0.1% or something (by the way is that what market_fee is and does it only apply to BTS?).

1) Options Market
2) Escrow / Payment Channels (off-chain micro payments combined with arbitration)
3) Scripting Engine

For starters...

Yes, yes, and yes.

But if the Options Market is anything like the Collateralized Bond Market (no automatic matching with market engine, no margin calls), I can't imagine it would be too difficult or too much of a penalty in performance for anyone to implement the Bond Market, Options Market, and Escrow / Payment Channels as smart contracts using the Scripting Engine. In which case, I would think #3 would be next priority feature over #1 and #2. Or is there a reason why #1 and #2 need to be native?

That also makes me wonder. Would the scripting engine allow for the creation of new object types (I think that means the x in 1.x.y ID numbers)? And how would long-term memory usage of objects stored in the database be fairly charged? I guess I will just have to wait until it is time for the official proposals.

Also, I was going to suggest another feature that would allow UIAs to elect their own delegates which could jointly control an account (like BTS elected delegates) and end up running child/side chains nested into the BitShares blockchain, but then I discovered this.    I also love the references to SPV in that page.   Very excited for all the other things in store for 2.0 that haven't yet been discussed.

I will tell you what might be a solution to this, and something I have been thinking on and likely will happen unless we see changes to the program.

If wallet provider WP1 referred a new user they get all their transactions in the program.

WP2 comes along that includes a kitchen sink. That user at WP1 wants to go there, but WP2 is only offering the kitchen sink for newly referred users. So they will either FORCE new user registration for their wallet using their refer.

You will likely just see a situation where accounts are left abandoned. With the ability to be able to transfer names as I understand it so far, I can have joeblow1 at WP1 and then needing to register a new user at WP2, I create joeblow2 and then transfer my name joeblow1 over (I may not have that right.. I haven't dived into how that works yet). The original BTS address is left abandoned on WP1 system.. jowblow goes about his merry way.

This is what the refer program is going to encourage in the wallet space at least the way I see it.

I would fine this very annoying. First, you could transfer the account name from one account ID to another. Let me even assume there is a way to do that without even losing your web-of-trust and reputation. Then all other balances assets could also be moved from the original account ID to the new one.

Even with all of this inconvenience, there is the incredibly annoying and costly fact that if you had upgraded to lifetime member, you would have to reupgrade with the new account. So you would pay WP1 $80 even though you used their services for a short time before moving to a much better service. Then, to keep the low 4 cent fees in the new wallet, you have to pay another $100 ($80 going to WP2)! The switching costs would be too high which is not good for incentivizing innovation in a free market with low barriers to entry.

I think you should absolutely be able to move your existing account from one wallet host to another (or have the same account coexist in multiple wallets at the same time) by simply importing in your brain key. I am confident this will be done (I would be surprised and disappointed if the intended culture in BitShares 2.0 was to not have this be the case). But that does mean that even if a business provides a really good wallet, they cannot rely on revenue purely from referral fees.